SQL Server 2K / 2K5 / 2K8 i dyski SSD: konkretne optymalizacje?

Czy ktoś tutaj używa programu SQL Server na dyskach półprzewodnikowych? Czy znalazłeś jakieś konkretne wskazówki dotyczące optymalizacji? Szczególnie interesują mnie sposoby zmniejszenia częstotliwości, z jaką SQL Server wykonuje małe losowe operacje zapisu, ponieważ są one nemezis wydajności dysków SSD, szczególnie dysków MLC SSD.

Istnieją oczywiście oczywiste optymalizacje, które można wykonać: dane wymagające dużej ilości odczytu powinny być podawane z dysku SSD, a rzeczy wymagające dużej ilości zapisu należy pozostawić tradycyjnym wirującym dyskom. Obejmuje to oczywiście dzienniki transakcji!

Biorąc pod uwagę wystarczający budżet, oczywiście chciałoby się używać dysków SLC SSD, takich jak seria X25-E lub Vertex Ex, lub różnych ofert na poziomie korporacyjnym. Ale interesują mnie również wskazówki, które mogą przynieść korzyści dla konfiguracji MLC SSD. Myślę, że to interesujący obszar. Jeden z klientów moich klientów ma niewielki budżet i zbiór danych, który ogromnie się powiększył, i czeka ich kompletne przepisanie prawie stu zapytań w celu utrzymania przyzwoitego poziomu wydajności. Mam jednak podejrzane podejrzenie, że mniej niż 500 USD pamięci RAM i SSD może przynieść im większy wzrost wydajności niż tysiące (być może dziesiątki tysięcy) dolarów warte czasu dewelopera.

Nie jestem pewien, co masz na myśli, mówiąc o ograniczeniu liczby małych, losowych zapisów, które robi SQL Server. SQL Server zapisuje strony danych tylko podczas punktów kontrolnych - więc jedynym sposobem ograniczenia liczby zapisów jest zmiana interwału punktu kontrolnego lub rezygnacja z wielu operacji wkładki wewnątrzmacicznej. Miałeś na myśli coś innego?

We wszystkich implementacjach dysków SSD, które widziałem (garstka), jest to coś zupełnie przeciwnego do tego, co sugerujesz - najlepsze wykorzystanie dysków SSD wydaje się być do dzienników transakcji o dużej ilości zapisu i tempdb - w zasadzie gdzie jest największy I Wąskie gardło podsystemu / O i wsuń tam dyski SSD - czas wyszukiwania i opóźnienia są zmniejszane do niskiej stałej.

Zapoznaj się z tym artykułem badawczym opracowanym przez MS (niestety niezbyt szczegółowo opisującym specyfikę SQL Server): Migracja pamięci serwera na dyski SSD: Analiza kompromisów .

Mam nadzieję że to pomoże!

Nie można modyfikować właściwości IO serwerów SQL. Podstawową jednostką dostępu do dysku dla plików danych jest strona o wielkości 8 KB. Zapisze je głównie podczas punktu kontrolnego, ale również leniwie je napisze, kiedy będzie to możliwe.
SQL nie czeka na zakończenie zapisu na dysku danych przed zwróceniem, tylko zapisy dziennika muszą zostać zakończone. Jeśli możesz przechowywać tylko jeden dziennik bazy danych na dysku, będzie to sekwencyjny zapis i będzie dobrze na normalnych szybkich dyskach twardych.
Wydajność spadła z punktu widzenia SQL, gdy musi czytać dyski. Jeśli możesz dać mu więcej pamięci, SQL będzie przechowywać więcej stron danych w pamięci, co jest szybsze niż jakikolwiek dysk, dysk SSD lub inny. Oczywiście można również zmniejszyć liczbę odczytów dysku, tworząc odpowiednie indeksy. Oczekuję, że dysk SSD również pomógłby w tych odczytach, ponieważ prawdopodobnie są one losowe i czekają na ruch głowic napędu.
Nie wiem o jakiej wielkości bazy danych mówimy tutaj, ale czy możesz chcieć rzucić okiem na HyperOS. Tworzą dyski sata, które są po prostu obciążeniem pamięci RAM DDR2, z dyskiem SSD lub dyskiem 2,5 cala jako kopią zapasową. Wzorzec dostępu do serwera nie będzie wtedy mieć znaczenia. Jednak nie umieszczałbym dzienników na czymś takim. Dzienniki są tym, co utrzymuje spójność danych, muszą iść na niezawodnym nośniku i pomimo tworzenia kopii zapasowej dysku SSD i baterii, a serwer prawdopodobnie ma zasilacz UPS itp., Nadal nie czułbym się łatwo z powodu braku moich dzienników na prawdziwym dysku twardym w jakiejś macierzy RAID odpornej na awarie.

Małe losowe operacje to nemezis tradycyjnych dysków ze względu na opóźnienie poszukiwania przez głowę ... Dyski SSD doskonale nadają się do rozwiązania tego problemu.

Przy długich, sekwencyjnych operacjach standardowe dyski działają całkiem dobrze, więc używanie dysków SSD nie miałoby sensu (oczywiście z punktu widzenia wydajności).

Nie dodawaj jeszcze tutaj, aby dodać do wątku komentarza, ale jeśli ustawisz wielkość strony DB / licznik odczytu wielokrotnego dla czegokolwiek na dyskach SSD na wielokrotność rozmiaru strony SSD, nie powinno to stanowić problemu.

Dawno nie pracowałem na SQL Server, więc nie jestem pewien, czy te opcje są tam dostępne. Robiłem Oracle i DB2 przez ostatnie kilka lat i to rozwiałoby twoje obawy, ponieważ DB byłby odpowiednio dostosowany do charakterystyki dysku.

Polecam wyrównywanie partycji, na której przechowywane są pliki bazy danych.

Poleciłbym również zdecydować, co będzie się działo z RAID 0 dla perf (ldf i TempDB), i umieść krytyczne dane na RAID 1 (mdf).

Po trzecie, naprawdę powinieneś zaktualizować oprogramowanie napędu, a także oprogramowanie / sterowniki kontrolera SATA. W ten sposób dajesz firmie sprzętowej i jej twórcom szansę na optymalizację wydajności.