Czy warto mieć katalog główny instancji SQL Server na osobnym dysku?

29

Wiem, że można zmienić wiele domyślnych ścieżek podczas instalowania programu SQL Server i generalnie podczas instalacji zmieniam foldery danych i dzienników na osobne dyski (zazwyczaj D i E), jednak ostatnio otrzymałem preinstalowany komputer, na którym działa nazwa instancji inna niż domyślna i skonfigurował katalog główny instancji na dysk D wraz z plikami mdf. Oznacza to, że na czymś, co zwykle byłby względnie czystym dyskiem z tylko folderami i plikami baz danych, mam teraz pełną instalację plików binarnych programu SQL Server.

tzn. teraz mam następujące:

C:\Program Files\Microsoft SQL Server\ --Base Install
D:\Microsoft SQL Server\MSSQL10_50.MyInstance --Instance Binaries
D:\Microsoft SQL Server\MSSQL10_50.MyInstance\MSSQL\DATA --Data Files
E:\Microsoft SQL Server\MSSQL10_50.MyInstance\MSSQL\LOGS --Log Files

Gdzie normalnie biegałbym z czymś takim jak:

C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\ --Base Install & Default Instance Binaries
D:\MSSQL\DATA --Data Files
E:\MSSQL\LOGS --Log Files

Rozumiem, dlaczego posiadanie osobnego folderu binarnego jest konieczne, ale nie rozumiem, dlaczego warto umieścić wszystkie te pliki binarne na osobnym dysku.

Czy ktoś może mi powiedzieć, dlaczego może to być rozsądne? A może to po prostu nie robi różnicy? Wydaje mi się po prostu strasznie niechlujny ...

adhocgeek
źródło

Odpowiedzi:

23

Jeśli chodzi o podział katalogu głównego instancji, istnieje kilka argumentów przemawiających za tym.

  1. Niektórzy ludzie opowiadają się za tym, aby dysk „C” był dedykowany tylko systemowi operacyjnemu i plikom binarnym systemu operacyjnego. Może to dać ci różne opcje odzyskiwania w przypadku awarii na dysku C, może pomóc powstrzymać system operacyjny przed powodowaniem lub odbieraniem problemów związanych z przestrzenią podczas udostępniania innym aplikacjom.
  2. Izolujesz pliki binarne programu SQL Server od innych programów i zapewniasz dostępność niektórych krytycznych folderów, takich jak folder Logs, do którego prowadzą dzienniki błędów - ten folder musi być dostępny dla serwerów SQL Server podczas uruchamiania. Zasadniczo chronisz się przed innymi.

Możesz umieścić pliki binarne / instancji SQL Server w tym samym miejscu, w którym zwykle umieszczasz inne pliki programu. Ale jeśli to zrobisz - przynajmniej pamiętaj o zabraniu systemowych plików bazy danych i potencjalnie domyślnej lokalizacji kopii zapasowej i przeniesieniu jej w inne miejsce ...

Oto, co zwykle robię, gdy otrzymuję nieograniczoną liczbę liter dysku do zabawy (przynajmniej .. Listy nie są tutaj ważne):

  • C - Pliki na poziomie systemu operacyjnego i systemu. Tylko
  • D - Pliki programów dla wszystkich aplikacji (w tym SQL Server)
  • S - Pliki poziomu instancji / systemowe bazy danych SQL Server i pliki dziennika zwykle (z wyjątkiem TempDB) (uwaga .. Jeśli mam wiele instancji, nie utworzę 4 z nich. Umieściłbym wszystkie pliki binarne SQL dla wszystkich instancji na S w większości sytuacji, z folderami zapewniającymi separację)

( ED - Kolejna uwaga - często nie mam dostępnego dysku „S”. Na koniec pliki systemowe bazy danych dla Master, Model, MSDB i DB zasobów znajdują się na tym samym dysku, co niektóre z twoich użytkowników pliki bazy danych, ale w osobnym folderze dla logicznej separacji, aby mniej zamieszać, to nie koniec świata).

  • F - Pliki danych dla baz danych użytkowników
  • L - Dysk pliku dziennika dla baz danych użytkowników
  • T - TempDB
  • X - Dysk kopii zapasowej (choć w wielu przypadkach wybieram przesyłanie kopii zapasowej do dysku sieciowego, nie płacąc za kopię po kopii zapasowej i od razu wykonuję kopię zapasową w magazynie w innym miejscu).

Często będę mieć więcej danych i dyski dziennika, a czasem inny dysk TempDB. Dodawaj w wielu instancjach, aby szybko zabrakło liter dysku. Z pewnością możesz uciec od umieszczenia plików poziomu instancji na C :. I przeprowadzam wiele kontroli kondycji dla klientów, którzy zostali tak skonfigurowani - i nigdy nie mówię „och, wow .. musimy to teraz naprawić” - Teraz, jeśli są tam również ich pliki TempDB, zazwyczaj niech zmienią to. Czasami przenoszą także swoją bazę danych master i MSDB.

Ale świat się nie skończy, jeśli nie podzielisz tych rzeczy. Myślę, że korzyścią jest po prostu oddzielenie plików. Jako DBA powinieneś mieć zdrową paranoję wokół innych ról w firmie, innych aplikacji, innych instalacji itp. Im bardziej możesz izolować się od potencjalnych konfliktów, tym lepiej będziesz. Daje to jeszcze więcej opcji ponownej instalacji i odzyskiwania. Więc tak, oddziel swoje pliki binarne od C .. Ale nie radzę szaleć na osobnym dysku dla każdej instancji ...

Mike Walsh
źródło
3

Cóż, w systemie Windows jest tylko 26 możliwych liter dysków. 1
Ale masz możliwość użycia punktów montowania. 2)

Jeśli więc chcesz zainstalować 25 różnych serwerów (SQL, Web, ...) na jednym komputerze, warto mieć jedną literę dysku dla jednego z serwerów.
Ale jeśli masz tylko jeden serwer, rozsądniej byłoby mieć różne litery dysków dla plików dziennika, bazy danych i plików programów.
Możesz także podzielić pliki dziennika / bazy danych / programu, jeśli znajdują się one w różnych folderach.

  1. zatrzymaj serwer SQL
  2. dodaj partycję
  3. skopiuj wszystkie pliki bazy danych na partycję
  4. zmień punkt montowania na folder, w którym były pliki bazy danych (na przykład: d: \ baza danych)
  5. skończone
gnomix
źródło
To wcale nie odpowiada na pytanie. Nie pytałem o litery dysków ani punkty montowania, pytałem, dlaczego warto umieścić instancję root na osobnym dysku. Ponieważ są to pliki systemowe, dla mnie sensowne jest pozostawienie ich na dysku systemowym.
adhocgeek
1
Przepraszam, że cię źle zrozumiałem. Dobrym punktem na umieszczenie wszystkiego, co należy do SQL na jednym dysku, może być prostota skryptu kopii zapasowej, który należy uruchomić tylko na tym dysku. Ale jeśli umieścisz wszystko tylko na jednym dysku, baza danych, pliki binarne i dzienniki powinny znajdować się w osobnych folderach. Doszedłem do punktu z punktami montowania, że ​​możesz reorganizować Dane na różnych partycjach bez zmiany całego systemu.
@gnomix Zawsze możesz edytować swoje odpowiedzi (i pytania), klikając link „edytuj” pod nimi.
dezso,
@gnomix Prostota potencjalnych skryptów kopii zapasowych jest jednym z głównych powodów, dla których zwykle umieszczam Dane i Dzienniki na ich własnych dyskach, ale nigdy nie musiałem tworzyć kopii zapasowych plików systemowych. Chciałbym wiedzieć, czy jest to powszechny wymóg. Mój instynkt sugeruje mi, że umieszczenie plików systemowych na dysku niesystemowym może powodować problemy.
adhocgeek
1
Ponadto rozdzielenie dysku na dwie lub więcej partycji tak naprawdę nie pomoże we / wy dysku. Ale tak, całkowicie się z tobą zgadzam. Sprawia, że ​​umieszczanie plików bazy danych w katalogu głównym dysku jest o wiele ładniejsze, a także łatwiejsze do zauważenia. Zwykle umieszczam wszystko w katalogach, takich jak D: \ Data E: \ Logs F: \ Kopia zapasowa, ...
user1207758