Optymalna konfiguracja dysku dla SQL Server 2008R2

Mam dość zajęty serwer bazy danych z programem SQL Server 2008 R2, który ma następującą konfigurację:

• SATA RAID 1 (2 dyski) - OS / Programy
• SAS RAID 10 (4 dyski) - pliki bazy danych SQL (dane i dzienniki)
• SAS RAID 1 (2 dyski) - TempDB (dane i logi)

Zakładając, że nie mogę dodać dodatkowych dysków do tego serwera, czy w najlepszy sposób wykorzystałem dostępną konfigurację? Czy powinienem rozważyć inny schemat, w którym na przykład dzienniki są izolowane od plików danych?

Aktualizacja:

Dla tych, którzy poprosili o dalsze szczegóły dotyczące sprzętu:

• Dyski SATA (używane do partycji OS / Program) to: WD 7200 RPM 3 Gb / s 3,5 cala SATA
• Dyski SAS używane w innych macierzach to: Seagate 15K RPM 6 Gb / s 3,5 cala SAS
• Używany kontroler RAID to: LSI 9260-8i SAS / SATA 6 Gb 8 port

Aktualizacja 2:

W oparciu o informacje zwrotne, jakie otrzymaliśmy, wygląda na to mam następujące żywotne opcje do wyboru - będę przyzna nagrodę dla kogoś, kto może mi powiedzieć, co jest prawdopodobne, aby być najlepszym w środowisku, że już przedstawione:

1. Zostaw wszystko tak, jak jest - prawdopodobnie nie zrobię nic lepszego
2. Przenieś moje 2 dyski SAS RAID 1 do mojej istniejącej macierzy RAID 10, aby w sumie składało się z 6 dysków
3. Przenieś moje pliki dziennika na SAS RAID 1 i / lub przenieś TempDB (dane lub logi) z powrotem na RAID 10

Warianty tego pytania pojawiają się częściowo:

• Kompilacja SQL Server
• Pomóż mi wybrać kombinację poziomu RAID dla instancji SQL Server 2008
• Jak skonfigurować te dyski na serwerze SQL do konfiguracji BI?

Od czasu do czasu odbywają się również walki pojedynków na temat „najlepszych praktyk” dotyczących separacji danych / logów.

• Wprowadzanie transakcji Zaloguj się na osobnej objętości [półprzewodnikowej]?
• SQL Server - Oddzielanie danych, dziennika i plików TempDB w sieci SAN

Bez bardziej szczegółowej analizy tego, co robi ten serwer, obowiązują te same porady, co podane wcześniej.

• RAID 1 dla systemu operacyjnego
• RAID 10 (6 dysków) dla danych / logów / tempdb

Rzadko ma miejsce punkt podziału przy tak małej liczbie wrzecion. Pojedyncza tablica o większej pojemności procesorów IOP zazwyczaj pochłonie grudki i uderzenia obciążenia lepiej niż 2 mniejsze tablice.

Jednym z wariantów, który może być wart przetestowania, jest umieszczenie tempdb na dysku systemu operacyjnego. Zrób to tylko wtedy, gdy masz reprezentatywne obciążenie, które możesz wielokrotnie powtarzać, aby zapewnić rzetelne porównanie konfiguracji. Jeśli zdecydujesz się na takie ustawienie w produkcji, upewnij się, że wzrost tempdb jest ograniczony, abyś nie wykorzystał przypadkowo całego wolnego miejsca na dysku systemu operacyjnego.

Biorąc pod uwagę, że dyski OS są podstawkami 7200RPM, byłbym zaskoczony, gdyby tempdb na konfiguracji dysku OS przyniósł jakąkolwiek korzyść.

Wszystko zależy od obciążenia, ale przy zaledwie 6 dyskach ogranicza to twoje opcje. Jeśli obciążenie nie jest silnie zależne od tempdb w przypadku sortowania, tabel mieszania i izolacji migawek, lepiej byłoby użyć razem 6 dysków SAS w RAID 10. Jeśli jednak znasz lub masz takie dane, aby to udowodnić tempdb jest mocno wykorzystywany, więc powinieneś trzymać go oddzielnie, tak jak masz.

To bardzo zależy od tego, co rozumiesz przez „bardzo zajęty”: różne wzorce obciążenia (pisz ciężkie lub nie, operacje masowe wspólne lub nie, poziom równoczesnego dostępu, aby wymienić, ale trzy z wielu zmiennych) mogą mieć drastyczny wpływ na wykonanie dowolnego układu wrzeciona.

W przypadku trudnej do zapisu sytuacji oddzielanie dzienników od danych może mieć znaczącą różnicę, ponieważ każdy zapis wymaga aktualizacji zarówno dziennika, jak i plików danych, a zatem wymaga znacznej dodatkowej przewrócenia, jeśli oba zestawy plików znajdują się na tym samym zestawie wrzecion .

Bez dalszych odniesień do twojego obciążenia (i specyfikacji tych napędów i dowolnego kontrolera, który jest między nimi a maszyną) byłbym skłonny przejść na trzy woluminy: jeden dla programów OS + i tempdb (dane), jeden dla głównej bazy danych dane, a trzeci dla dzienników (zarówno bazy danych tempdb, jak i główne bazy danych).

Oczywiście, jeśli wszystkie obciążenia są bardzo lekkie w operacjach zapisu, nie powinieneś zbyt wiele czasu martwić się o oddzielenie danych i dzienników, ponieważ spowoduje to niewielką różnicę w wydajności i poświęcenie im całego woluminu byłoby dość marnotrawstwem dostępności przestrzeń.

Rzeczywista odpowiedź zależy od twoich potrzeb, ale ogólnie „umieszczaj dane i loguj się na różnych tablicach” ma większe znaczenie niż „umieszczaj tempdb na własnej tablicy”.

Biorąc pod uwagę liczbę dostępnych dysków, moim punktem wyjścia będzie:

1. Dwa dyski, RAID 1 - system operacyjny, pliki wykonywalne, plik stronicowania.
2. Cztery dyski, RAID 5 - wszystkie pliki danych (alternatywnie RAID 1 + 0)
3. Dwa dyski, RAID 1 - wszystkie pliki dziennika

Co należy zrobić, to użyć SQLIO do przetestowania wydajności różnych konfiguracji dysków.

W zależności od tego, do czego używasz DB (OLTP vs magazynowanie) twoja konfiguracja wygląda jak dobra ogólna konfiguracja. Gdybyś miał więcej dysków, miałbyś więcej opcji.

Możesz uzyskać lepszą wydajność, jeśli zmienisz dysk TempDB na RAID 0 (pasek). Zwiększa to ryzyko niepowodzenia, ale ponieważ TempDB buforuje tylko dane, nie możesz utracić danych. Dlatego większość ludzi uważa to za rozsądny kompromis. Po prostu zapasowy (lub zapasowy).

Jednej rzeczy, o której nie wspomniałeś, ale możesz spróbować (jeśli jeszcze tego nie zrobiłeś): Microsoft zaleca podzielenie TempDB na kilka plików (jeden na procesor). Oczywiście najlepiej jest, jeśli znajdują się one na osobnych dyskach, ale po prostu oddzielne pliki pomagają. http://msdn.microsoft.com/en-us/library/ms175527(v=SQL.105).aspx