Optymalne rozmieszczenie plików tempdb, mdf i ldf w SQL Server 2012 na dyskach SSD?

9

Zdaję sobie sprawę, że jest to prawdopodobnie bardzo otwarte pytanie i odpowiedzi mogą się różnić, ale jakie jest optymalne miejsce dla plików tempdb, mdf i ldf w SQL Server 2012, gdy mówimy o dyskach SSD?

Przed nowym zakupem miałem istniejący dysk SSD z zainstalowanymi plikami podstawowymi programu SQL Server 2012 i tempdb oraz miałem zarówno plik mdf / ldf na dysku twardym 7200 obr / min. Następnie kupiłem 2 dyski SSD z oryginalnym zamiarem umieszczenia mdf na jednym, a ldf na drugim.

Ale, po przeczytaniu w nim więcej, osobne dyski fizyczne dla plików mdf i ldf tak naprawdę nie mają zastosowania, jeśli chodzi o dyski SSD. Poprawny?

Tak więc myślałem o następujących kwestiach:

SSD 1 - SQL Server 2012 Core Files i Windows
SSD 2 - tempdb
SSD 3 - mdf i ldf

Jeśli to robi różnicę, będzie to poświęcone tylko jednej bazie danych, więc nie będzie rywalizacji między wieloma bazami danych.

Czy moja „myśląca” konfiguracja jest dobra, czy po prostu marnotrawstwem (tj. Nie ma powodu, aby oddzielać tempdb), gdzie mam teraz dodatkowy dysk SSD, aby móc korzystać z niego gdzie indziej?

Kevin
źródło
2
Czy tolerancja na błędy jest opcją w twojej konfiguracji? Jeśli twoja baza danych jest w ogóle ważna, dyski mdf i ldf powinny być przechowywane na osobnych dyskach odpornych na uszkodzenia (np. Dublowane).
datagod
3
Jednym z potencjalnych problemów, które widzę w twojej konfiguracji, jest to, że nie uwzględniłeś awarii pojedynczego napędu. Jeśli masz tylko trzy dyski SSD do pracy, zaleciłbym rozważenie macierzy RAID5 i umieszczenie w niej wszystkich plików związanych z programem SQL Server.
Matt M
2
Czy jest to serwer warstwy produkcyjnej, czy martwisz się, czy ulegnie awarii w przypadku awarii dysku?
Jon Seigel
1
Zapomniałem wspomnieć, że odporność na awarie części nie stanowi problemu, ponieważ kopie zapasowe danych są wykonywane w nocy, ale są to głównie dane statyczne, które mogę łatwo zastąpić, nawet jeśli kopie zapasowe nie byłyby możliwe. Jedynymi danymi dynamicznymi są głównie rejestrowanie / kontrola, która nie jest zależna. Wszelkie niewielkie przerwy w pracy, które miałbym ręcznie w przypadku tworzenia kopii zapasowej, są dopuszczalne.
Kevin
Doceniam odpowiedzi. Mam dodatkowe pytanie dotyczące „czy najlepiej sformatować dyski SSD do 64k bloków?”, Ale nie znam tutaj formatu. Czy powinienem opublikować to jako nowe pytanie, czy jest to w porządku?
Kevin

Odpowiedzi:

5

Ale, po przeczytaniu w nim więcej, osobne dyski fizyczne dla plików mdf i ldf tak naprawdę nie mają zastosowania, jeśli chodzi o dyski SSD. Poprawny?

Pierwotny powód dzielenia plików dziennika i danych na osobne dyski to 2-krotnie - opóźnienie i przepustowość na dyskach.

Dyski SSD nie usuwają tych ograniczeń, ale znacznie zmniejszają / zwiększają limity (około 7,9 ms dla odczytu z pojedynczym dyskiem twardym w porównaniu do 0,1 ms dla odczytu z pojedynczego dysku SSD).

Tak więc ostatecznie tak i nie - nie stosuje się tak DUŻO, jak w przypadku dysków twardych, ale te granice nadal istnieją i nadal można je spełnić. Wszystko zależy od obciążenia pracą.

Czy moja „myśląca” konfiguracja jest dobra, czy po prostu marnotrawstwem (tj. Nie ma powodu, aby oddzielać tempdb), gdzie mam teraz dodatkowy dysk SSD, aby móc korzystać z niego gdzie indziej?

Przy założeniu, że

  • Masz 3 fizyczne dyski SSD
  • Masz 1 fizyczny dysk twardy
  • Potrzebujesz danych, aby były zbędne, ale niekoniecznie sam system

Proponowana konfiguracja miałaby kilka problemów (jak wspomniano wcześniej), a awaria pojedynczego dysku jest najważniejsza.

Możesz wybrać coś takiego.

Pojedynczy dysk 7200 obr./min -
macierz RAID 5 systemu Windows (3 dyski SSD) - w podziale na 4 dyski (D dla danych, L dla dzienników, S dla zamiany i T dla temp.)

LUB

Pojedynczy dysk o prędkości 7200 obr./min -
Pojedynczy dysk SSD systemu Windows - Temp and Swap
RAID 1 array (2 SSDs) - Dane i dzienniki

Osobiście preferuję odciążanie systemu Windows na dysk inny niż SSD, gdy masz tylko ograniczoną liczbę, ale to całkowicie zależy od tego, co robi serwer i od tego, jakie ryzyko chcesz podjąć.

Kok
źródło