Znaczenie lokalizacji instalacji Microsoft SQL Server

10

Mam serwer z tanim wolnym dyskiem i drogim szybkim dyskiem.

Chcę używać drogiego dysku do wszystkich rzeczy, w których ważne jest, aby był szybki, takich jak moje bazy danych.

Aby zaoszczędzić pieniądze, chcę używać wolnego dysku do wszystkiego, co nie ma większego znaczenia, czy jest szybkie czy wolne, na przykład do tworzenia kopii zapasowych.

Teraz moje pytanie brzmi: czy powinienem zainstalować mój Microsoft SQL Server na wolnym lub szybkim dysku?

(Żeby było jasne, umieszczę moje bazy danych na szybkim dysku bez względu na wszystko, więc moje pytanie dotyczy tylko lokalizacji samej instalacji)

Niels Brinch
źródło
3
Dlaczego w ogóle bierzesz to pod uwagę, biorąc pod uwagę, że SSD o niskiej prędkości 120 GB to (a) TANIO i (b) super szybki i (c) wystarczająco dobry do wszystkiego, co mądre w programach OS +? Przeniosłem wszystkie systemy operacyjne do 120 GB SSD 2 lata temu, a koszt naprawdę nie miał znaczenia - w tym czasie. Teraz jest to jeszcze mniej istotne.
TomTom,
Chcesz zaufać krytycznej bazie danych na dysku SSD? Przypomnij mi, żebym nigdy nie robił z tobą interesów ...
Shadur
2
@Shadur what a flamebait. Tak, umieszczę go na dysku RAID 10 skonfigurowanym w oparciu o SSD, który jest lokalnie replikowany na 2 inne dyski i co noc tworzony jest backup w zdalnej lokalizacji. Witamy w dekadzie!
Niels Brinch,
@TomTom masz oczywiście rację, ale w tym przypadku jestem raczej wrażliwy na koszty, dlatego nawet zawracam sobie głowę tego rodzaju hiperoptymalizacją. Z każdym rokiem moje pytanie będzie coraz bardziej nieistotne, tak jak przypuszczam w przypadku większości pytań tutaj.
Niels Brinch,
@NielsBrinch Cent Smart and Pound Foolish. Poważnie.
TomTom,

Odpowiedzi:

11

To rodzaj opinii, ale chciałbym umieścić pliki binarne programu SQL Server na wolnym dysku. Pliki binarne są dość powszechne na dysku systemu operacyjnego (chociaż niektórzy tego nie znoszą) lub na wolniejszym dysku.

Zdecydowanie chcesz jednak pamiętać o umieszczeniu systemowych baz danych, zwłaszcza tempdb, na szybszym dysku. W rzeczywistości często używa się tempdb.

Jest to zgodne z pomocą pary z artykułów znalazłem, że może być przydatna.

Do pomyślenia są także kopie zapasowe dziennika transakcji, a ja jestem rozdarty, ponieważ chcesz LDF na szybszym dysku i chcesz także tworzyć kopie zapasowe na innym dysku niż miejsce, w którym znajdują się bazy danych, ale byłoby lepiej, gdyby były na szybszy dysk. Musisz zadzwonić, ale prawdopodobnie wrócę do wolniejszego dysku i narzekam na to. ;)

Katherine Villyard
źródło
Dziękuję Ci. Czy mówisz, że nie wpływa to w szczególności na wydajność, czy instalacja serwera SQL (pliki binarne itp.) Znajduje się na wolnym lub szybkim dysku?
Niels Brinch,
1
Nie to, że zauważyłem. I jest to dość powszechna konfiguracja.
Katherine Villyard,
6
Katherine ma rację, ponieważ same pliki binarne nie są szczególnie związane z IO. Ogólnie rzecz biorąc, umieszczenie plików binarnych na szybkim dysku skraca czas ładowania, ale rzadko wpływa na ogólną szybkość działania, ponieważ kod działa z pamięci. Jeśli pliki binarne nie są często restartowane, nie będzie to miało większego znaczenia.
Corey,
@Corey dziękuję bardzo za wyjaśnienie na temat punktu. Właśnie tego szukałem.
Niels Brinch,
6

Chciałbym odpowiedzieć na dość dobrą odpowiedź Katherine Villyard .

Zależy to nieco od zamierzonego wykorzystania bazy danych.
Jeśli spodziewasz się wielu operacji zapisu, śmiało i umieść swoje pliki .mdforaz .ndfpliki na szybszym dysku.

Jeśli jednak twoja baza danych jest na ogół dość statyczna (na przykład udostępniająca treści internetowe). Zapytania nie różnią się zbytnio, istnieje duże prawdopodobieństwo, że w pamięci pojawi się duża liczba zapytań, a nawet buforowane po stronie aplikacji. W którym momencie jesteś lepiej wyłączyć za pomocą szybszego dysku dla swoich .ldf, tempdbi kopii zapasowych.

Podobnie, jeśli spodziewasz się wiele dużych zapytań, takich jak na OLAPbazie danych, jesteś lepiej przechowywania .mdf, tempdbna szybszym dysku. I zakładanie .ldfwolniejszych dysków, ponieważ często nie będzie to częścią wąskiego gardła.

W każdym razie nie przejmuj się umieszczaniem plików binarnych na szybkim dysku, zwykle umieszczamy je na wolnym dysku (nie w systemie, jeśli można tego uniknąć).
Ponadto, nie rozłączaj się, próbując pobrać zarówno pliki, jak .ldfi .mdfpliki na szybki dysk, zazwyczaj są one oddzielane, gdy tylko jest to możliwe.

Podsumowując, przejrzyj ładunek, aby zobaczyć, jakie będzie najbardziej prawdopodobne wąskie gardło.

Reaces
źródło
3

Masz rzeczy do tyłu. Wiem, że jest to sprzeczne z intuicją, ale chcesz tworzyć kopie zapasowe (szczególnie kopie zapasowe dziennika transakcji) na szybkim dysku, a pliki mdf / ldf (z godnym uwagi wyjątkiem tempdb) na wolnym dysku.

Możesz myśleć o tym tak, jakby Sql Server przechowywał dwie reprezentacje twoich danych. Pliki MDF + LDF reprezentują bieżący stan bazy danych, a kopia zapasowa (w tym kopie zapasowe dziennika transakcji od czasu ostatniej pełnej kopii zapasowej) reprezentuje to, czego potrzebujesz, aby przywrócić aktualny stan bazy danych w przypadku awarii. Chcesz, aby te dwie reprezentacje były od siebie oddzielone, aby zdarzenie, które zniszczy jedną reprezentację, nie uszkodzi również innej reprezentacji.

Okazuje się, że wydajność SQL Server ma tendencję do zależeć na DUŻO więcej o tym, jak szybko można zapisywać pliki dzienników transakcji i ich kopie zapasowe ponad jak szybko można uzyskać dostęp do plików MDF. Oznacza to, że musisz zdecydowanie rozważyć umieszczenie kopii zapasowych na szybkim dysku (idealnie byłoby dodać do serwera mały dysk SSD, którego można użyć do plików ldf, aby nadać im szybkość, zachowując jednocześnie separację od kopii zapasowych). Niestety pozostawia to wolny dysk dla plików MDF, ale znowu: nie będzie to miało większego znaczenia, niż myślisz.

Warto zauważyć, że powyższe zakłada, że ​​masz wystarczającą ilość pamięci RAM, że wykonujesz typowe obciążenia i że planujesz używać trybu pełnego odzyskiwania, zamiast prostego. Dodatkowo, system operacyjny i sam zainstalowany program Sql Server można umieścić na wolnym dysku, choć oczywiście prawdopodobnie chcesz tyle, ile masz miejsca na życie na szybkim dysku.

Joel Coel
źródło
Przez kopie zapasowe rozumiem pliki, które nie są używane, ale po prostu są przechowywane. Na szybkim dysku umieściłem zarówno pliki mdf, jak i ldf. To dla mnie wiadomość, że mdf jest w porządku, aby umieścić na wolnym dysku, co było interesującą i nieoczekiwaną informacją.
Niels Brinch,
1
Nie chcesz, aby mdf był na tym samym dysku co kopie zapasowe / logi. MDF reprezentuje aktualny stan bazy danych. Kopia zapasowa + LDF reprezentuje to, czego potrzebujesz, aby przywrócić bazę danych do jej obecnego stanu. Chcesz, aby dwie reprezentacje były od siebie oddzielone, więc zdarzenie, które je zniszczy, nie uszkodzi również drugiego. A ponieważ dzienniki i kopie zapasowe powinny znajdować się na szybkim dysku (wydajność zależy o wiele bardziej od tego, jak szybko można zapisać do pliku ldf niż od tego, jak szybko można zapisać do pliku mdf), oznacza to, że mdf powinien przejść na wolny dysk.
Joel Coel,
Zamierzam edytować większość powyższego komentarza w odpowiedzi.
Joel Coel,
1
Nie jestem pewien, dlaczego mówisz o tym .ldfi musisz .mdfbyć oddzielony w przypadku katastrofy ... Ogólnie nie zakłada się, że użyjesz jednego z nich do odzyskiwania po awarii, po to są kopie zapasowe. Jeśli utrata danych nie jest tak bliska zeru, jak to możliwe, masz bardzo częste kopie zapasowe dziennika, nie polegasz na samym pliku dziennika.
Reaces,
@Reaces Masz rację. Miałem pierdnięcie mózgu i pisałem palcami pliki LDF, myśląc o kopiach zapasowych TRN w mojej głowie. Ogólne myśli się utrzymują, ale muszę to znacznie poprawić, aby to wyjaśnić (pracując nad tym teraz).
Joel Coel,