2021-12-09

Nyheter inom SQL Server och Azure SQL

Vi börjar med att definiera vad vi menar med SQL Server respektive Azure SQL. SQL Server är produktnamnet på databasmotorn (plus annat) som vi ursprungligen har haft på det vi idag kallar on-premise. Idag har Microsoft två managerade miljöer i sitt Azure-moln för SQL Server. I botten så är det SQL Server, men Microsoft hanterar delar av DBA-arbetet åt oss. Dessa managerade miljöer är:

• Azure SQL Database. Enskilda databaser i Azure. Kallas ofta bara SQL Database eller SQL Db.
• Azure SQL Managed Instances. Hela instanser i Azure. Kallas ofta bara Managed Instances eller MI.
• SQL Server on Azure Virtual Machines. SQL Server installerad i en virtuell maskin som ligger i Azure. Kallas ibland för SQL Virtual Machines.

Vänta nu, sa jag inte två (2) managerade miljöer i Azure SQL familjen? Jodå. Det går att diskutera om SQL Virtual Machine ska ses som managerad miljö och ibland ser man också hur Azure SQL bara inkluderar SQL Db och MI. Det är så att säga i betraktarens ögon hur man vill klassa SQL Virtual Machines. Sen finns det ett antal varianter av de managerade miljöerna, som ex elastic pools, serverless, hyperscale, olika service tiers att välja på etc.

Säkerhet

Grundarkitekuren för säkerhet består, dvs man representeras av en eller flera principals (logins, users, roller) och olika typer av rättigheter för securables (tabell, schema, databas, instance etc.) tilldelas till principals. Nedan är exempel på saker som har hänt på senare tid:

Always Encrypted krypterar data innan det anländer till SQL Server. Dvs ex en DBA kan göra SELECT så mycket hen vill. Utan krypteringsnyckeln så ser man krypterat data.
Row-Level security låter oss specificera villkor för om en användare ska få se rader eller ej.
Vulnerability Assessment finns i SQL Server Management Studio och Azure och låter oss aktivt leta efter säkerhetssvagheter som exempelvis SQL Injection.
Dynamic Data Masking låter oss maskera data för vissa användare. Ex att man ser * för de sista fyra siffrorna i ett personnummer.

SQL-språket

Visst händer det saker här också. Inte lika flashigt att skriva om kanske, men för den som skriver SQL kan vissa av dessa saker vara väldigt värdefulla.

Till exempel:

Temporala tabeller, som låter oss göra en tidsresa i en tabell för att se hur datan såg ut vid en tidigare tidpunkt.
Äntligen får vi ett vettigt felmeddelande när data skulle trunkeras. Dvs vi får nu reda på själva värdet och inte bara *att* data inte ”får plats”.
Även om vi inte har fått en JSON datatyp så har vi fått annan funktionalitet för att massera JSON data. Exempel är FOR JSON, OPENJSON() och JSON_VALUE().
Det tog ända till 2017 innan vi kan aggregera strängar utan att behöva stöka till det med FOR XML PATH eller liknande, dvs nu kan vi göra sånt med STRING_AGG() funktionen som är en aggregate function.

Index

Kan det hända så mycket på denna front? Ett index är väl … ett index, kanske man tänker. Men vi har sex olika typer av index där vissa har tillkommit på senare tid. Kanske att ni kan ersätta åtta ”vanliga” index som skapats för att stöda olika rapporter med ett kolumn-index? Kolumnindex kan man säga har blivit ett ”fullvärdigt index” i och med SQL server 2016, dvs de kan även vara intressanta utanför traditionella datalager. Eller att vi kan avbryta och återuppta skapande och ombyggnad av index. Inte nog med det, vi kan tömma transaktionsloggen ”mitt i” en sådan operation. Detta går också vid oväntade avbrott, som en omstart eller fail-over.

Prestanda

Det känns som om man jagar sin egen svans här. Prestandaförbättringar på olika nivåer äts upp av större och större datamängder, komplexitet etc. Lyckligtvis så börjar vi se roliga saker på prestandasidan på senare tid. Där Microsoft tidigare kände sig begränsade att göra förändringar som kan påverka planer, så låter de sen några versioner kompatibilitetsnivån för databasen styra prestandakompatibilitet. Där börjar nu ny funktionalitet i optimizern framträda, som exempelvis:

Batch-mode även om vi inte involverar kolumn-index i frågan.
Inlining av scalar functions, dvs om vi har tur så behöver inte användandet av egna scalar functions innebära en prestandakatastrof.
Adaptive memory grant, dvs om optimizer “gissar fel” för hur mycket minne som behövs för vissa operationer kan den justera det för senare exekveringar på sina cachade planer.

Hög tillgänglighet och återhämtning efter katastrof

HA/DR är ett evigt ämne. Ju mer beroende vi blir av våra databaser, desto viktigare blir det att de är tillgängliga. En bra infrastruktur är en bra start, men saker kan fortfarande hända.

För en managerad lösning i Azure, dvs SQL Db och Managed Instances, så är HA/DR inbakat redan från början. Antingen finns det något som påminner om Failover Cluster i botten, eller en Availability Group. Plus att vi kan få ”extra” genom en knapptryckning (i stort sett). Annars så får vi sålla mellan alternativ som finns, där huvudalternativen är Failover Clustered Instances (FCI), Log Shipping och Availability Groups (AG). Just FCI och AG går ju under paraplynamnet Always On.

AG är där Microsoft har investerat sedan det kom i 2012. Vi kan ha fler och fler noder i ett kluster, avlasta den primära med olika saker, vara utan ett kluster (där man bara ska se den som en ”read-scale” lösning), ha AG på Standard Edition (bara en databas per ”grupp”) etc. Det sker förbättringar i varje version på denna front.

Vad händer framöver?

Tja…, vi får se! Det har i skrivande stund börja släppas lite information om planerade förbättringar i SQL Server 2022.

Till exempel:

Fail-over till Azure Managed Instance. Dvs vi kan ha en MI i Azure som en katastroflösning. Det blir intressant att se implementationen för denna då den väcker många frågeställningar! Det finns presentationer där vi ser en MI databas som man tar backup på och sen gör restore av den på en on-premise SQL Server. Det är helt nytt, eftersom SQL Database och Managed Instance ju ”alltid” är av högre version än vi har on-premise. Sug på den ni!
Flera planer i cache för samma SQL-fråga. Kanske inte låter så spännande, men det är säkert flera som har slitit sitt hår pga att ”parameter sniffing” ibland har jobbar mot oss. Varje förbättring inom detta område är varmt välkommen. Med andra ord så kan vi ha olika planer i cache beroende på parametervärde (dvs selektivitet).
Eller vad sägs om att ha koll på förändringar som görs mot på vårt data, via block-chain teknologi: SQL Server Ledger?
Apropå prestanda så ser det ut som om Query Store kommer att vara på per default när man skapar en ny databas. Eller vad sägs om feedback via Query Store för att få hjälp med att justera MAXDOP och CE nivå för våra frågor?

I skrivande stund finns det inte mycket publik information om SQL Server 2022, så detaljer och andra nyheter lär dyka upp allt eftersom.

Författare:
Tibor Karaszi
Ämnesexpert

Tibor har jobbat med SQL Server sedan version 1.0, år 1989 och har hållit kurser kring SQL Server åt Cornerstone sedan 1994. Numera är han konsult, men anlitas flitigt av Cornerstone. Hans specialitet är SQL motorn inklusive saker som prestanda, SQL-språket - drift och DBA relaterade ämnen helt enkelt. Genom åren har han varit medförfattare till flera böcker och anlitad som talare vid diverse sammanhang, både i Sverige och utomlands.