SQL Server 2016 nyheter

By | augusti 17, 2015

Det är nu dags igen för en ny version av SQL Server. Som Microsoft har meddelat kommer den att heta SQL Server 2016 och den kommer att lanseras …gissningsvis… någon gång 2016.

Redan nu går det att testa en beta-version (eller Community Technology Preview som det numera heter). Den finns att ladda ned här.

Det är alltid med stor entusiasm jag har sett fram emot när nya SQL Server släpps. Denna gång är definitivt ingen besvikelse. SQL Server 2016 är laddat med många väldigt intressanta nyheter. Jag skall här sammanfatta de allra viktigaste.

Förbättrad In-Memory OLTP

In-Memory OLTP var en av de absoluta huvudnyheterna i SQL Server 2014. Tekniken hade dock vissa begränsningar, så som det brukar vara när första versionen av någon ny teknologi släpps. I SQL Server 2016 har det kommit många stora förbättringar:

  • ALTER support. Du kan lägga till/ta bort kolumner och index utan att behöva skapa om tabellen.
  • Möjlighet att ändra BUCKET_COUNT för Hash-index. Tidigare behövde de skapa om tabellen.
  • Stöd för native user-defined scalar functions. Tidigare var det bara stored procedures som kunde vara native (alltså jobba direkt med In-Memory tabeller).
  • ALTER procedure-kommandot fungerar nu även för native stored procedures.
  • Kraftigt förbättrat T-SQL stöd. Nu kan du använda det mesta ifrån T-SQL även i native stored procedures.

Med dessa förbättringar så blir det mycket enklare att nyttja In-Memory OLTP jämfört med SQL Server 2014 eftersom det krävs mindre omskrivning av programkod.

Möjlighet att kombinera In-Memory OLTP och Columnstore Indexes

Columnstore indexes var en av de största nyheterna i SQL Server 2012 och gjorde att framförallt SQL-frågor från Business Intelligence-verktyg och datalager kör oerhört mycket snabbare och effektivare. Sedan kom In-Memory tekniken i SQL Server 2014. Tyvärr gick det inte att kombinera dessa två.

Från och med SQL Server 2016 så går det att skapa Columnstore Indexes på In-Memory OLTP tabeller. Dina Columnstore Indexes kommer då också att hanteras ”In-Memory”, och kommer att leda till att typiska datalager-frågor kommer att gå ännu mycket snabbare.

Kombinationen In-Memory OLTP och Columnstore Indexes stöds även av AlwaysOn, vilket innebär att dina Columnstore Indexes kan läsas även från sekundärerna. Du kan alltså uppdatera din data på en server och köra dina Business Intelligence SQL-frågor mot en annan server som kommer att ha ett ständigt uppdaterat Columnstore Index.

Query store

Har ditt system plötsligt blivit långsamt och du undrar varför? Query store kan liknas vid ”svarta lådan” i ett flygplan. Du kan använda Query store för att få en historik över vad som har hänt. Query store sparar:

  • SQL-frågornas text
  • Prestandainformation
  • Exekveringsplaner

Det går också att få prestandainformation via Live Query Statistics (LQS) medan en SQL-fråga körs, samt se hur långt SQL-frågan har kommit i exekveringsplanen. Detta är naturligtvis oerhört värdefullt för felsökning och prestandaoptimering.

Temporal tables

Visst händer det att du vill backa tillbaka i tiden och se hur en tabell såg ut vid en tidigare tidpunkt? Det går naturligtvis att bygga lösningar som loggar alla förändringar i en tabell, men det är en hel del extra jobb. Tänk om databasen hade inbyggt stöd för detta istället?

Temporal tables behåller automatiskt en historik över förändringar, så att du i dina SQL-frågor kan skriva exempelvis:

SELECT * FROM Tabell FOR SYSTEM_TIME AS OF '2015-08-01'

Detta är naturligtvis mycket användbart i scenarion för Business Intelligence, felsökning och spårning.

Always Encrypted

Ibland innehåller databaser känslig information som helst inte skall kunna läsas av teknisk supportpersonal. Det kan vara exempelvis patientjournaler, där det ju råder strikta krav för vilka läkare och sjukvårdspersonal som får se data, men där teknisk supportpersonal har adminrättigheter till databasservern och därmed kan läsa allt.

Med hjälp av Always Encrypted skyddas data så att inte ens personer med adminrättigheter kan läsa. Detta sker med hjälp av kryptering där krypteringsnyckeln förvaras på klientsidan (applikationsservern). Krypteringsnyckeln hanteras av drivrutinerna på klientsidan och skickas aldrig till databasservern.

Krypteringen konfigureras kolumnvis. Det går alltså att välja vilka kolumner som skall skyddas och med vilken krypteringsmetod. Inga direkta förändringar krävs i applikationen, men eftersom krypteringen påverkar jämförbarheten och möjligheterna till joins så kan det krävas omskrivning av SQL-frågor.

Radbaserad säkerhet

Det har naturligtvis även tidigare varit möjligt att bygga egna lösningar för att styra användarnas åtkomst ända ned på radnivå genom exempelvis vyer och hänvisa användarna till dem, men i SQL Server 2016 finns denna funktionalitet inbyggd. En fördel med Row-Level Security i SQL Server 2016 är att behörigheterna gäller direkt i tabellerna utan att man behöver gå omvägen via exempelvis vyer, vilket innebär att det går att implementera säkerheten utan att behöva ändra i några applikationer.

Behörigheterna styrs genom:

  • Predicate functions som innehåller själva logiken för att avgöra behörigheterna
  • Filter predicates som kopplar predicate functions till tabeller
  • Security policies som grupperar ihop filter predicates

Förbättrad AlwaysOn

AlwaysOn Availability Groups introducerades i SQL Server 2012 som ny lösning för High Availability och Disaster Recovery (HADR). Utöver att användas för HADR så kan AlwaysOn också användas för att minska belastningen på en server genom att styra SQL-frågor mot sekundärservrar (som har en kopia på samma data som primärservern). Nytt i SQL Server 2016 är att sekundärservrarna kan lastbalanseras så att SQL-frågorna fördelas jämnt mellan dem.

En annan nyhet är att det går att ha upp till tre synkrona sekundärer, som kan användas för automatisk failover (till skillnad från asynkrona sekundärer som inte kan ha automatisk failover).

SSIS stöds också av AlwaysOn från och med SQL Server 2016. SSISDB kan läggas till i en AlwaysOn Availability Group.

Stöd för JSON

I SQL Server 2000 introducerades stöd för XML, eftersom det är ett vanligt format att läsa och skriva till. Nu i SQL Server 2016 så kommer ett motsvarande stöd för JSON-formatet:

  • Läsa JSON-data
  • Exportera data till JSON-format
  • Kombinera JSON-data med relational-data

Till skillnad mot XML så har ingen ny datatyp introducerats, utan allt sker genom funktioner och tillägg till T-SQL syntaxen. Exempelvis ”FOR JSON” motsvarar ”FOR XML”.

Integration med R

R är ett populärt programmeringsspråk för statistiker och data scientists. I SQL Server 2016 kommer stöd för R inbyggt i databasmotorn, så att det är möjligt att använda det i SQL-miljö och med sin relationella data. Det blir därmed mycket enklare att göra avancerade analyser direkt i SQL Server 2016.

Polybase

Polybase introducerades i SQL Server Parallel Data Warehouse 2012 och möjliggjorde att du kunde ställa T-SQL frågor mot extern data i Hadoop. Polybase gjorde det möjligt att i samma T-SQL fråga blanda data från SQL Servers egna tabeller med extern data.

Nu blir Polybase även tillgängligt i SQL Server 2016. Framför allt för detta användbart i datalager där det nu i SQL Server 2016 blir möjligt att arbeta med extrema volymer semistrukturerad data genom Hadoop och Azure Blob Storages.

Stretch Databases

Från och med SQL Server 2016 går det att skapa hybriddatabaser, som lagras delvis fysiskt lokalt och delvis i molnet (Azure). Tabeller kan flyttas till molnet utan att några förändringar behöver göras i applikationer.

Microsoft kallar dessa hybriddatabaser för Stretch Databases och det kan naturligtvis vara intressant för dem som vill slippa lagra stora databaser själva.

Referenser