Zalecana konfiguracja dysku / partycji dla programu SQL Server


14

Szukam porady dotyczącej najlepszego sposobu konfiguracji moich dysków / partycji dla programu SQL Server. Oto niektóre z moich głównych obaw:

Jak należy rozdzielić pliki SQL (pliki danych, logi, temp)?

Czy lepiej jest RAIDować wiele dysków twardych i podzielić miejsce na partycje, czy też utworzyć wiele macierzy RAID z mniejszą liczbą dysków dla każdej macierzy RAID?

Czy dane i pliki dziennika powinny być innego typu RAID?

Czy domyślne bazy danych (master, msdb itp.) Powinny znajdować się na C: czy powinny znajdować się w tym samym miejscu, co inne pliki danych / dzienników?

Odpowiedzi:


14

Oto miły post na blogu: http://sqlserveradvisor.blogspot.com/2009/03/sql-server-disk-configuration.html

Biała księga na temat wyrównywania dysku: http://msdn.microsoft.com/en-us/library/dd758814.aspx

Krótko mówiąc, twój system operacyjny powinien mieć RAID 1, twoje pliki danych na RAID 10 (najlepiej) i pliki dziennika na RAID 1.

Artykuł dotyczący wydajności SQL: http://www.sql-server-performance.com/faq/raid_1_raid_5_p1.aspx

PDF na temat 10 najlepszych wskazówek dotyczących najlepszej wydajności: http://www.stlssug.org/docs/Best_Practices_for_Performance.pdf

Pamiętaj również, aby umieścić TEMPDB na osobnym dysku ze względu na wydajność. Jestem pewien, że Paul Randal tu przyjdzie i za chwilę oszaleje.

MS mówi, dlaczego dla tempdb: http://msdn.microsoft.com/en-us/library/ms175527.aspx


@SQLChicken: Jeśli istnieje preferencja dla typu napędu -> SATA vs SAS, czy istnieje zalecenie? SAS zamiast SATA? (niezależnie od typu RAID itp.).
Pure.Krome

1
Dyski SAS, jeśli masz pieniądze, są lepsze od SATA ze względu na szybkość i niezawodność.
SQLChicken

11

To duże pytanie „to zależy”.

Nie mogę odpowiedzieć na pytanie, jak utworzyć dla ciebie pytanie dotyczące macierzy RAID, ponieważ nie jestem ekspertem od pamięci, ale mogę pomóc z resztą.

Pierwszą rzeczą, którą należy wziąć pod uwagę, jest obciążenie w różnych bazach danych - OLTP (odczyt / zapis) lub DSS / DW (głównie odczyt). W przypadku obciążeń odczytu / zapisu należy zwrócić uwagę na RAID 1 lub RAID 10 (RAID 1 + 0), ponieważ zapewniają one nadmiarowość i doskonałą wydajność odczytu / zapisu. W przypadku obciążeń głównie do odczytu można użyć RAID 5. Powodem, dla którego RAID 5 nie powinien być używany do obciążeń do odczytu / zapisu, jest obniżenie wydajności zapisu.

Dzienniki transakcji ze swej natury są do odczytu / zapisu (lub głównie do zapisu, w zależności od tego, czy używasz dziennika transakcji do czegokolwiek - np. Kopii zapasowych dziennika lub replikacji), dlatego nigdy nie powinno się go umieszczać na RAID 5.

Oznacza to, że w przypadku niektórych baz danych i obciążeń możesz mieć pliki danych na RAID 5 i pliki dziennika na RAID 1/10, a dla innych baz danych możesz mieć wszystko na RAID 1/10. Idąc dalej, jeśli masz partycjonowaną bazę danych, może ona zawierać głównie dane do odczytu i niektóre dane do odczytu / zapisu, być może nawet w tej samej tabeli. Można to podzielić na osobne aplikacjami, a następnie na każdej aplikacjach ustawić odpowiedni poziom RAID.

Oddzielenie rzeczywistych baz danych ponownie zależy od obciążenia pracą i możliwości bazowego podsystemu IO - na przykład może być wymagany wyższy stopień separacji do przechowywania rzeczy na poszczególnych macierzach RAID niż na SAN.

Tempdb jest specjalnym przypadkiem sam w sobie, ponieważ zwykle jest mocno obciążoną bazą danych i powinien być przechowywany oddzielnie od innych baz danych. Systemowe bazy danych nie powinny być intensywnie wykorzystywane i można je umieścić w dowolnym miejscu, o ile występuje nadmiarowość.

Oto link do białej księgi, którą pomogłem napisać, która powinna ci pomóc: Projekt fizycznego przechowywania danych . Upewnij się także, że podsystem IO może obsłużyć przewidywane obciążenie pracą - zobacz ten oficjalny dokument: Najlepsze praktyki we / wy przedwdrożeniowe . Na koniec upewnij się, że używasz prawidłowego rozmiaru paska RAID (zwykle 64 K lub więcej w nowszych systemach), prawidłowego rozmiaru jednostki alokacji NTFS (zwykle 64 K) oraz że w systemach wcześniejszych niż Windows Server 2008 poprawnie ustawiłeś przesunięcie partycji dysku . Aby uzyskać informacje na ich temat oraz wskazówki na ich temat i dlaczego należy je skonfigurować w ten sposób, zobacz ten wpis na blogu: Czy przesunięcia partycji dyskowych, rozmiary pasków RAID i jednostki alokacji NTFS są ustawione poprawnie? .

Linia Bototm: poznaj swoje obciążenie pracą i możliwości podsystemu IO, a następnie odpowiednio je zaimplementuj.

Mam nadzieję, że to ci pomoże.

PS Jeśli chodzi o tempdb, to jest duża paczka robaków na temat tego, jak powinieneś go skonfigurować i jest wiele różnych sprzecznych informacji. Napisałem obszerny post na blogu o konfiguracji pliku danych tempdb na błędnych przekonaniach dotyczących TF 1118 .


Świetny post Paul :)
Pure.Krome

1

Krótka odpowiedź dla serwerów, które skonfigurowałem, zawsze była

Loguje się na osobnych dyskach fizycznych, raid 1 lub 10 (striping + mirroring)

Baza danych na własnych dyskach, w zależności od potrzeb wydajnościowych, zwykle RAID5

Dużo pamięci podręcznej na kontrolerach RAID

Najlepiej ponownie przyklej system operacyjny i plik stronicowania Windows do osobnej tablicy, zwykle tylko do kopii lustrzanej (Raid 1). Dzięki temu wszystkie operacje zapisu są rozdzielone, więc duża wydajność nie pociąga za sobą wszystkiego.

Doświadczyłem w przeszłości, że zapisywanie bazy danych + zapisywanie dziennika + zapisywanie pliku strony spowoduje utratę tablicy Raid5, a wydajność pójdzie do cholery w koszyku. Problem polega na tym, że Twoja wydajność będzie w porządku w testowaniu, tworzeniu itp. Ale kiedy wejdziesz w produkcję i użycie gwałtownie wzrosną, ten problem będzie wyglądał „na niebiesko”, a skargi użytkowników gwałtownie wzrosną.


1

Są tu o wiele lepsi faceci MSSQL niż ja, ale ogólnie sugeruję, co następuje;

System operacyjny i kod na C: - powinny to być dyski lokalne, powinna to być para macierzy RAID1 - do tego używamy 2 x 2,5-calowych dysków SAS 146 GB 10krpm, ale możesz użyć 2 dysków SATA 7.2. Dane powinny znajdować się na dość szybkiej macierzy RAID 1/10, 5/50/6/60 o dowolnej wielkości - macierz RAID 1/10, 5/50/6/60 - trzymamy nasze na jednostkach FC SAN LUN, zwykle na grupie dysków „poziomu 2” / 10krpm . Dzienniki powinny znajdować się na osobnej bardzo BARDZO SZYBKO (15krpm) małej (10 GB lub mniejszej?) Parze macierzy RAID 1 - trzymamy nasze na FC SAN LUN, zwykle na bardzo małej grupie dysków „poziom 1” / 15krpm lub na „poziom 0” / grupa ssd.

Tak czy inaczej, chcesz, aby każda porcja na oddzielnych wrzecionach / macierzach była wydajna - oczywiście wszystko będzie działać na jednym dysku, ale myślę, że szukasz równowagi między wydajnością a kosztami.

Przechowujemy nasz master / tempdb w naszych regularnych bazach danych, ale możesz podzielić go na oddzielną tablicę danych LUN.

Mam nadzieję że to pomoże.


Ciekawe, że dyski z logami są małe. Czy to ma pomóc z prędkością zapisu? Czy dobrym pomysłem jest, aby dyski z plikami dziennika były tak małe, jak tylko potrafią dane?
Sean Howat

Daleki jestem od bycia ekspertem, ale wydaje nam się, że pozostają małe - twój przebieg może się różnić :)
Chopper3
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.