Sqlserver
 sql >> Baza danych >  >> RDS >> Sqlserver

Limity pamięci w SQL Server 2016 SP1

Kilka tygodni temu zrobiłem całkiem niezłą ofertę dotyczącą dodatku Service Pack 1 dla SQL Server 2016. Wiele funkcji zarezerwowanych wcześniej dla Enterprise Edition zostało udostępnionych w niższych edycjach i byłem zachwycony, gdy dowiedziałem się o tych zmianach.

Niemniej jednak spotykam się z kilkoma osobami, które są, powiedzmy, nieco mniej podekscytowane niż ja.

Należy pamiętać, że wprowadzone tutaj zmiany nie miały na celu zapewnienia pełnej zgodności funkcji we wszystkich edycjach; miały na celu stworzenie bardziej spójnego obszaru programistycznego. Teraz klienci mogą korzystać z funkcji takich jak In-Memory OLTP, Columnstore i kompresja, nie martwiąc się o docelową edycję – tylko o to, jak dobrze będą się skalować. Otwarto również kilka funkcji bezpieczeństwa, które tak naprawdę nie miały nic wspólnego z edycją. Najmniej rozumiałem ten, który był zawsze zaszyfrowany; Nie mogłem pojąć, dlaczego tylko klienci korporacyjni muszą chronić takie rzeczy, jak dane karty kredytowej. Przezroczyste szyfrowanie danych jest nadal tylko dla przedsiębiorstw, w wersjach wcześniejszych niż SQL Server 2019, ponieważ tak naprawdę nie jest to funkcja programowalna (albo jest włączona, albo nie).

Co tak naprawdę oferuje klientom Wersji standardowej?

Myślę, że największym problemem większości ludzi jest to, że maksymalna pamięć w wersji Standard Edition jest nadal ograniczona do 128 GB. Patrzą na to i mówią:„Jej, dzięki za wszystkie funkcje, ale limit pamięci oznacza, że ​​tak naprawdę nie mogę ich używać”.

Jednak zmiany powierzchni dają możliwość poprawy wydajności, nawet jeśli nie było to ich pierwotnym zamiarem (a nawet jeśli tak było – nie byłem na żadnym z tych spotkań). Przyjrzyjmy się bliżej małej części drobnym drukiem (z oficjalnych dokumentów):

Limity pamięci dla Enterprise/Standard w SQL Server 2016 SP1

Wnikliwy czytelnik zauważy, że zmieniło się sformułowanie limitu puli buforów, z:

Pamięć:maksymalna wykorzystywana pamięć na instancję

Do:

Pamięć:maksymalny rozmiar puli buforów na instancję

To jest lepszy opis tego, co naprawdę dzieje się w wersji Standard Edition:limit 128 GB tylko dla puli buforów, a inne rezerwacje pamięci mogą być większe (pomyśl o pulach takich jak pamięć podręczna planu). W efekcie serwer w wersji Standard Edition może wykorzystać 128 GB puli buforów, a wtedy maksymalna pamięć serwera może być wyższa i obsługiwać więcej pamięci używanej do innych rezerwacji. Podobnie, Express Edition jest teraz prawidłowo udokumentowany, aby używać 1,4 GB na pulę buforów.

Możesz również zauważyć bardzo specyficzne sformułowania w kolumnie znajdującej się najbardziej po lewej stronie (np. „na instancję” i „na bazę danych”) dotyczące funkcji, które są udostępniane w wersji Standard Edition po raz pierwszy. Aby być bardziej szczegółowym:

  • Instancja jest ograniczona do 128 GB pamięci dla puli buforów .
  • Instancja może mieć dodatkowy 32 GB przydzielone do obiektów Columnstore, ponad limit puli buforów.
  • Każda baza danych użytkowników w instancji może mieć dodatkowe 32 GB przydzielone do tabel zoptymalizowanych pod kątem pamięci, poza limitem puli buforów.

I żeby było jasne:Te limity pamięci dla ColumnStore i In-Memory OLTP NIE są odejmowane od limitu puli buforów , o ile serwer ma więcej niż 128 GB dostępnej pamięci. Jeśli serwer ma mniej niż 128 GB, zobaczysz, że te technologie konkurują z pamięcią puli buforów i w rzeczywistości są ograniczone do % maksymalnej pamięci serwera. Więcej szczegółów można znaleźć w tym poście od Parikshit Savjani z Microsoftu.

Nie mam pod ręką sprzętu, aby przetestować zakres tego, ale jeśli miałbyś maszynę z 256 GB lub 512 GB pamięci, teoretycznie mógłbyś wykorzystać to wszystko z jedną instancją Standard Edition, gdybyś mógł na przykład rozłożyć swój In - Dane pamięci w bazach danych w porcjach <=32 GB, co daje łącznie 128 GB + (32 GB * (liczba baz danych)). Jeśli chcesz używać ColumnStore zamiast In-Memory, możesz rozłożyć dane na wiele instancji, co daje (128 GB + 32 GB) * (liczba wystąpień). Możesz połączyć te strategie dla ((128 GB + 32 GB ColumnStore) * (liczba wystąpień)) + (32 GB w pamięci * (liczba baz danych * liczba wystąpień)).

Czy dzielenie danych w ten sposób jest praktyczne dla twojej aplikacji, nie jestem pewien; Ja tylko sugeruję, że to możliwe. Niektórzy z was mogą już robić niektóre z tych rzeczy, aby lepiej wykorzystać wersję Standard Edition na serwerach z ponad 128 GB pamięci.

W szczególności w przypadku ColumnStore, oprócz możliwości użycia 32 GB oprócz puli buforów, należy pamiętać, że kompresja, którą można tutaj uzyskać, oznacza, że ​​często można zmieścić o wiele więcej w tym limicie 32 GB niż w przypadku tych samych danych w tradycyjnym sklep rzędowy. A jeśli z jakiegoś powodu nie możesz użyć ColumnStore (lub nadal nie zmieści się on do 32 GB), możesz teraz zaimplementować tradycyjną kompresję stron lub wierszy – może to nie pozwolić na zmieszczenie całej bazy danych w puli buforów o pojemności 128 GB, ale może to umożliwić przechowywanie większej ilości danych w pamięci w dowolnym momencie.

Podobne rzeczy są możliwe w Express (na mniejszą skalę), gdzie możesz mieć 1,4 GB na pulę buforów, ale dodatkowe ~352 MB na instancję dla ColumnStore i ~352 MB na bazę danych dla OLTP w pamięci.

Ale wersja Enterprise wciąż ma wiele zalet

Istnieje wiele innych wyróżników, które pozwalają utrzymać zainteresowanie Enterprise Edition, poza nieograniczonymi limitami pamięci dookoła — od przebudowy online i skanów karuzeli po pełne grupy dostępności i wszystkie prawa do wirtualizacji, których możesz się trzymać. Nawet indeksy ColumnStore mają dobrze zdefiniowane ulepszenia wydajności zarezerwowane dla Enterprise Edition.

A więc tylko dlatego, że istnieją pewne techniki, które pozwolą ci wydobyć więcej z edycji standardowej, nie oznacza to, że będzie ona magicznie skalować się do twoich potrzeb w zakresie wydajności. Podobnie jak moje inne posty o „robieniu tego z ograniczonym budżetem” (np. partycjonowanie i czytelne pliki pomocnicze), możesz z pewnością poświęcić czas i wysiłek na wspólne rozwiązanie, ale zaprowadzi Cię to tylko do tej pory. Celem tego posta było po prostu zademonstrowanie, że dzięki wersji Standard Edition w wersji 2016 SP1 można osiągnąć więcej niż kiedykolwiek wcześniej.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. SQL Server 2005 Używanie DateAdd do dodawania dnia do daty

  2. Funkcje bezpieczeństwa w SQL Server 2017

  3. Jak zmienić schemat db na dbo

  4. Wewnętrzne elementy SQL Server:Plan Caching Pt. II – Ponowna kompilacja planów

  5. Koniec wsparcia dla SQL Server 2008 i 2008 R2