sql >> Databasteknik >  >> RDS >> Sqlserver

Prestandafördelar för SQL Server 2016 Enterprise Edition

Den 16 november 2016 tillkännagav Microsoft några mycket betydande ändringar för SQL Server 2016 Standard Edition, som implementerades i SQL Server 2016 Service Pack 1 (Build 13.0.4001.0). Många mycket användbara programmerbarhetsrelaterade funktioner som tidigare bara var tillgängliga i Enterprise Edition kommer nu att finnas tillgängliga i Standard Edition (och även i Web Edition och till och med Express Edition).

När du har en databasapplikation som använder SQL Server 2016 Standard Edition Service Pack 1 (eller till och med en lägre upplaga), kan du bara utföra en uppgradering till Enterprise Edition för att få ännu mer skalbarhet och prestanda, och dra nytta av de högre licensgränserna för sockets , kärnor och minne i Enterprise Edition, som beskrivs här.

Du kommer också att få de många andra inneboende prestandafördelarna som finns i Enterprise Edition, tillsammans med flera hanterbarhetsförbättringar som gör ditt liv så mycket enklare som DBA.

Columnstore Index

Om du använder Columnstore-index får du följande prestandafördelar automatiskt när du använder Enterprise Edition:

  • Aggregerad pushdown: Denna prestandafunktion ger ofta en 2X-4X frågeprestandaökning genom att skjuta kvalificerande aggregat till SCAN-noden, vilket minskar antalet rader som kommer ut från den iteratorn.
  • Indexbygga/ombygga: Enterprise Edition kan bygga/ombygga columnstore-index med flera processorkärnor, medan Standard Edition bara använder en processorkärna. Detta har en ganska betydande effekt på förfluten tid för dessa operationer, beroende på din hårdvara.
  • Lokala aggregat: Enterprise Edition kan använda lokala aggregationer för att filtrera antalet rader som passerar ut från en SCAN-nod, vilket minskar mängden arbete som behöver utföras av efterföljande frågenoder. Du kan bekräfta detta genom att leta efter attributet "ActualLocallyAggregatedRows" i XML för exekveringsplanen för frågan.
  • Single Instruction Multiple Data (SIMD)-optimeringar: Den här funktionen använder en uppsättning hårdvaruinstruktioner som kan bearbeta en mängd data i en enda instruktion, vilket dramatiskt påskyndar aggregerade operationer. Dessa hårdvaruinstruktioner finns på alla moderna processorer (som har AVX-stöd), men de används endast av Enterprise Edition.
  • Pushdown för strängpredikat: Den här prestandafunktionen kan förbättra prestandan för frågor som använder predikat(er) på strängkolumner genom att skjuta dessa predikat till SCAN-noden. Detta kan avsevärt minska mängden arbete som behöver utföras av efterföljande noder.
  • Grad av parallellism: Frågor i batchläge är begränsade till MAXDOP =2 på Standard Edition. Enterprise Edition kan använda alla kärnor som finns för instansen. Detta kan vara mycket betydelsefullt för större frågor på typisk, modern serverhårdvara.
  • Minnesgränser: Columnstore-objektpoolen är begränsad till 32 GB per instans på Standard Edition. Enterprise Edition har ingen minnesbegränsning för Columnstore-objektpoolen.

För att testa dessa prestandapåståenden körde jag några ganska enkla tester på Microsoft ContosoRetailDW-databasen på min Intel Core i7-6700K-arbetsstation. Jag har två namngivna instanser av SQL Server 2016 SP1 installerade, en med Standard Edition och den andra med Developer Edition (vilket motsvarar Enterprise Edition).

Alla konfigurationer och egenskaper på instansnivå och databasnivå är identiska mellan de två instanserna, och användar- och tempdb-databasfilplatserna finns i separata kataloger på samma separata flashlagringsenhet för varje instans. Databaskompatibilitetsnivån ändrades till 130 i båda fallen, och den underliggande Windows-konfigurationen och hårdvaran är densamma för båda instanserna. Den enda skillnaden här är versionen av varje instans.

Det första testet är en enkel fråga (anpassad från Niko Neugebauer) som tillåter SQL Server 2016 att använda samlad pushdown på FactOnlineSales-tabellen. Resultaten visas i tabell 1.

Utgåva Förfluten tid (ms)
Standardversion 30
Utvecklarversionen 1
Tidsskillnad 29
% förbättring 96,7 %

Tabell 1:Aggregerad Pushdown-jämförelse

Nästa test är att tajma hur lång tid det tar att bygga ett klustrat kolumnbutiksindex på tabellen FactOnlineSales med 12,6 miljoner rader. Resultaten visas i tabell 2.

Utgåva Förfluten tid (ms)
Standardversion 42 197
Utvecklarversionen 14 384
Tidsskillnad 27 813
% förbättring 65,9 %

Tabell 2:Skapa klustrad kolumnbutiksindexjämförelse

Nästa test är att tajma hur lång tid det tar att bygga om ett klustrat kolumnlagerindex på samma FactOnlineSales-tabell. Resultaten visas i tabell 3.

Utgåva Förfluten tid (ms)
Standardversion 33 105
Utvecklarversionen 11 460
Tidsskillnad 21 645
% förbättring 65,4 %

Tabell 3:Återskapa klustrad kolumnbutiksindexjämförelse

Nästa test är en annan enkel fråga som tillåter SQL Server 2016 att använda lokal aggregering på FactOnlineSales-tabellen. Resultaten visas i tabell 4.

Utgåva Förfluten tid (ms)
Standardversion 122
Utvecklarversionen 83
Tidsskillnad 39
% förbättring 32,0 %

Tabell 4:Lokal aggregationsjämförelse

Nästa test är en annan enkel fråga som gör det möjligt för SQL Server 2016 att använda pushdown för strängpredikat i tabellerna FactOnlineSales och DimPromotion. Resultaten visas i tabell 5.

Utgåva Förfluten tid (ms)
Standardversion 2 683
Utvecklarversionen 1 221
Tidsskillnad 1 466
% förbättring 54,6 %

Tabell 5:Jämförelse av strängpredikat pushdown

Det här är bara några enkla exempel på de inbyggda prestandafördelarna för Columnstore-index i SQL Server 2016 Enterprise Edition jämfört med SQL Server 2016 Standard Edition på samma hårdvara. Om du verkligen vill dyka in i Columnstore-index (vilket kan vara en mycket effektiv funktion för vissa arbetsbelastningar), bör du bokmärka och läsa Niko Neugebauers långa serie av inlägg på columnstore.net.

DBCC CHECKDB-prestanda

En annan förbättring av hanterbarhetsprestanda som finns på SQL Server 2016 Enterprise Edition är DBCC CHECKDB-prestanda. På Standard Edition använder DBCC CHECKDB bara en processorkärna, medan den kan använda alla tillgängliga kärnor på Enterprise Edition. Detta beteende är oförändrat från tidigare versioner av SQL Server. SQL Server 2016 tillåter dig att begränsa antalet kärnor som DBCC CHECKDB kan använda med ett nytt WITH (MAXDOP =x)-alternativ.

Att köra DBCC CHECKDB med alternativet WITH PHYSICAL_ONLY på en något större databas (cirka 38 GB) som jag har, gav resultaten som visas i Tabell 6.

Utgåva Förfluten tid (ms)
Standardversion 58 492
Utvecklarversionen 24 897
Tidsskillnad 33 595
% förbättring 57,4 %

Tabell 6:DBCC CHECKDB MED PHYSICAL_ONLY Jämförelse

Att köra en standard DBCC CHECKDB på samma databas gav resultaten som visas i Tabell 7.

Utgåva Förfluten tid (ms)
Standardversion 435 039
Utvecklarversionen 119 767
Tidsskillnad 315 272
% förbättring 72,5 %

Tabell 7:DBCC CHECKDB-jämförelse

En mycket viktig faktor i DBCC CHECKDB-prestanda är den sekventiella läsprestandan från alla LUN:er där din databasdatafil(er) finns. Du kan enkelt kontrollera detta genom att köra ett BACKUP DATABASE-kommando till en NUL-enhet (se till att använda alternativen COPY_ONLY och NO_COMPRESSION). Detta kommer att visa dig din effektiva sekventiella läsprestanda, som visas i det här exemplet från min arbetsstation:

BACKUP DATABAS bearbetade framgångsrikt 5048514 sidor på 16,115 sekunder (2447,502 MB/sek).

Tänk på att alla dessa tester gjordes på en enda, fyrkärnig stationär processor. En multi-socket server med många fler totala processorkärnor kommer att visa ännu mer av en prestandaförbättring i många av dessa tester.

Poängen med allt detta är att visa några konkreta exempel på de prestandaförbättringar du kan se, helt enkelt genom att uppgradera från SQL Server 2016 Standard Edition SP1 till SQL Server 2016 Enterprise Edition SP1, på samma hårdvara, utan att göra några databas- eller applikationsändringar . Den här listan är på intet sätt uttömmande, eftersom det också finns många andra fördelar.


  1. Hur man uppdaterar från SELECT i SQL Server

  2. Vikten av bra databasdesign (och 7 steg för att uppnå det)

  3. Vad är skillnaden mellan INNER JOIN, LEFT JOIN, RIGHT JOIN och FULL JOIN?

  4. Hur man visar den aktuella inställningen för nollutdata i PostgreSQL (psql)