Sqlserver
 sql >> база данни >  >> RDS >> Sqlserver

Ограничения на паметта в SQL Server 2016 SP1

Преди няколко седмици направих доста голяма сделка относно SQL Server 2016 Service Pack 1. Много функции, запазени по-рано за Enterprise Edition, бяха пуснати в по-ниски издания и бях възторжен да науча за тези промени.

Въпреки това виждам няколко души, които са, да кажем, малко по-малко развълнувани от мен.

Важно е да се има предвид, че промените тук не са имали за цел да осигурят пълен паритет на функциите във всички издания; те бяха със специфичната цел да създадат по-последователна програмна повърхност. Сега клиентите могат да използват функции като In-Memory OLTP, Columnstore и компресия, без да се притесняват за целевото издание(а) – само за това колко добре ще се мащабират. Отворени са и няколко функции за сигурност, които всъщност нямат нищо общо с изданието. Този, който най-малко разбрах, беше винаги криптиран; Не можах да разбера защо само клиентите на Enterprise трябва да защитават неща като данни за кредитни карти. Прозрачното шифроване на данни все още е само за предприятия във версии, по-стари от SQL Server 2019, защото това всъщност не е функция за програмиране (или е включена, или не).

И какво всъщност има в това за клиентите на стандартното издание?

Мисля, че най-големият проблем, който повечето хора имат, е, че максималната памет в Standard Edition все още е ограничена до 128 GB. Те гледат това и казват:„О, благодаря за всички функции, но ограничението на паметта означава, че не мога да ги използвам“.

Въпреки това, промените в площта на повърхността водят до възможности за подобряване на производителността, дори ако това не е било първоначалното им намерение (или дори да беше – не бях в нито една от тези срещи). Нека разгледаме по-отблизо малка част от дребния шрифт (от официалните документи):

Ограничения на паметта за Enterprise/Standard в SQL Server 2016 SP1

Проницателният читател ще забележи, че формулировката на лимита на буферния пул се е променила от:

Памет:Максимално използвана памет за екземпляр

До:

Памет:максимален размер на буферния пул на екземпляр

Това е по-добро описание на това, което наистина се случва в Standard Edition:ограничение от 128 GB само за буферния пул, а други резервации на паметта могат да бъдат надвишаващи това (помислете за пулове като плановия кеш). Така че на практика сървърът със стандартно издание може да използва 128 GB буферен пул, тогава максималната памет на сървъра може да бъде по-висока и да поддържа повече памет, използвана за други резервации. По същия начин, Express Edition вече е правилно документирано да използва 1,4 GB за буферния пул.

Може също да забележите някои много специфични формулировки в тази най-лява колона (напр. „на екземпляр“ и „на база данни“) за функциите, които се показват в Standard Edition за първи път. За да бъдем по-конкретни:

  • Екземплярът е ограничен до 128 GB памет за буферния пул .
  • Екземплярът може да има допълнителен 32 GB, разпределени на обекти в Columnstore, над и над лимита на буферния пул.
  • Всяка потребителска база данни в екземпляра може да има допълнителна 32 GB, разпределени за оптимизирани за памет таблици, над и над лимита на буферния пул.

И за да бъдем кристално ясни:Тези ограничения на паметта за ColumnStore и In-Memory OLTP НЕ се изваждат от лимита на буферния пул , стига сървърът да разполага с повече от 128 GB налична памет. Ако сървърът има по-малко от 128 GB, ще видите, че тези технологии се конкурират с паметта на буферния пул и всъщност ще бъдат ограничени до % от максималната памет на сървъра. Повече подробности са налични в тази публикация от Парикшит Савджани на Microsoft.

Нямам удобен хардуер, за да тествам степента на това, но ако имате машина с 256 GB или 512 GB памет, теоретично бихте могли да използвате всичко с един екземпляр на Standard Edition, ако можете – например – да разпространите своя In -Данни от паметта в бази данни в <=32GB парчета, за общо 128GB + (32GB * (# бази данни)). Ако искате да използвате ColumnStore вместо In-Memory, можете да разпределите данните си в множество екземпляри, като ви дадете (128GB + 32GB) * (# екземпляри). И бихте могли да комбинирате тези стратегии за ((128GB + 32GB ColumnStore) * (# екземпляри)) + (32GB In-Memory * (# бази данни * # екземпляри)).

Дали разбиването на вашите данни по този начин е практично за вашето приложение, не съм сигурен; Само предполагам, че е възможно. Някои от вас може вече да правят някои от тези неща, за да използват по-добре стандартното издание на сървъри с повече от 128 GB памет.

Специално с ColumnStore, освен че ви е позволено да използвате 32GB в допълнение към буферния пул, имайте предвид, че компресията, която можете да получите тук, означава, че често можете да поберете много повече в това ограничение от 32GB, отколкото бихте могли със същите данни в традиционните ред-магазин. И ако не можете да използвате ColumnStore по някаква причина (или пак няма да се побере в 32GB), вече можете да приложите традиционна компресия на страници или редове – това може да не ви позволи да поберете цялата си база данни в 128GB буферния пул, но може да позволи повече от вашите данни да бъдат в паметта по всяко време.

Подобни неща са възможни в Express (в по-нисък мащаб), където можете да имате 1,4GB за буферен пул, но допълнителни ~352MB на екземпляр за ColumnStore и ~352MB на база данни за In-Memory OLTP.

Но Enterprise Edition все още има много предимства

Има много други отличителни черти, за да поддържате интереса към Enterprise Edition, освен неограничените ограничения на паметта навсякъде – от онлайн преструктуриране и сканиране на въртележки до пълни групи за наличност и всички права за виртуализация, с които можете да се захванете. Дори индексите на ColumnStore имат добре дефинирани подобрения на производителността, запазени за Enterprise Edition.

Така че само защото има някои техники, които ще ви позволят да извлечете повече от Standard Edition, това не означава, че то магически ще се мащабира, за да отговори на вашите нужди за производителност. Подобно на другите ми публикации за „да го направите с бюджет“ (например разделяне и четими вторични елементи), със сигурност можете да отделите време и усилия за събиране на решение, но това ще ви стигне само дотук. Целта на тази публикация беше просто да демонстрира, че можете да стигнете по-далеч със Standard Edition в 2016 SP1, отколкото някога сте могли преди.


  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 2017

  2. T-SQL Как да създавам динамично таблици в съхранени процедури?

  3. Външен ключ към непървичен ключ

  4. Какви са някои начини за достъп до Microsoft SQL Server от Linux?

  5. Как да вмъкнете редове в таблица на SQL Server чрез GUI за редактиране на редове на таблица - SQL Server / TSQL урок, част 101