sql >> Database >  >> RDS >> Sqlserver

Gedachten over SQL Server 2019-edities

Nu ik aan mijn eerste PASS Summit in een paar jaar begin, is het moeilijk om mijn opwinding over de nieuwste versie van SQL Server te bedwingen. Ik heb Bob Ward (@bobwardms) geholpen met de technische bewerking van zijn meest recente boek, "SQL Server 2019 Revealed", en ben tijdens de CTP- en RC-cycli actief betrokken geweest bij de productteams en mijn MVP-collega's. Ik heb zelfs het zeer exclusieve SQL Server 2019 Airlift-evenement in Redmond in de eerste week van oktober bijgewoond - en hoewel het te laat was om feedback te geven die van invloed zou zijn op RTM, heb ik verschillende constructieve suggesties gedaan die we hopelijk in een CU zullen zien ( of zo laat als vNext).

Het product is nog niet vrijgegeven, althans op het moment van schrijven, maar ze zijn begonnen vorm te geven aan welke functies (en dat zijn er veel) in welke edities beschikbaar zullen zijn. Zoals je je misschien herinnert, openden ze in SQL Server 2016 SP1 alle functies van het programmeeroppervlak voor alle edities, en veel (maar zeker niet alle) prestatie- en beschikbaarheidsfuncties. Ik schreef hierover in een bericht met de titel "A Big Deal:SQL Server 2016 Service Pack 1." Dit was een zeer opwindende tijd en ik wilde gewoon wat gedachten delen over de hits en missers in de nieuwste versie.

hits

  • Versneld databaseherstel is in Standard-editie . Dit was gemakkelijk de grootste verrassing voor mij, omdat ik dacht dat het een Enterprise Edition-functie zou zijn. Het is een beschikbaarheidsfunctie, omdat het de failover- en hersteltijd drastisch kan verminderen, en het kan ook als een prestatiefunctie worden beschouwd, omdat je nu dezelfde lokale versieopslag kunt gebruiken voor zaken als RCSI in plaats van de versieopslag in tempdb te delen. Je kunt zelfs de lokale versieopslag in zijn eigen bestandsgroep plaatsen, wat geen optie was toen ik in maart over de functie schreef. Het is fantastisch om dit in alle edities beschikbaar te hebben, maar je moet ervoor zorgen dat je je werklast vergelijkt met een baseline.
  • Transparante gegevenscodering (TDE) is nu beschikbaar in de standaardversie . Houd er rekening mee dat de documentatie niet definitief is, dit is een grote verandering voor veel winkels, en het is logisch dat zo'n belangrijk beveiligingskenmerk geen onderscheidende factor zou moeten zijn voor de duurste editie. Het is noch een prestatie noch een beschikbaarheidsfunctie, en een basis, verstandige gegevensbeveiliging zou geen extra kosten mogen kosten, IMHO. Nike Neugebauer is het daarmee eens. Always Encrypted en andere functies zoals beveiliging op rijniveau en dynamische gegevensmaskering zijn beschikbaar in alle edities, maar ze passen niet altijd in de "gemakkelijke knop"-oplossing waarnaar klanten op zoek zijn.
  • Scalaire UDF-invoering is in alle edities – zelfs Express . Dit is een geweldige functie die in wezen alle slechte prestaties verbergt die je gebruikte om te krijgen van inefficiënte scalaire, door de gebruiker gedefinieerde functies (ik schreef voor het eerst over deze functie een jaar geleden). Het verbaast me dat deze niet alleen voor Enterprise is - het hadden net geïndexeerde weergaven kunnen zijn, waarbij de functionaliteit overal beschikbaar is, maar het gedrag is beter (althans standaard) in Enterprise Edition. Ik ben blij dat iedereen hiervan profiteert.
  • Setup biedt betere real-world aanbevelingen . Dit is niet per se een item op de lijst met functies, maar er zijn enkele nieuwe opties en suggesties rond MAXDOP en min/max-servergeheugen waarvan ik denk dat het geweldige toevoegingen zijn en waarmee mensen hun instanties vanaf het begin beter kunnen configureren:

    Nieuw MaxDOP-scherm in setup ( klik om te vergroten)

    Nieuw geheugenscherm in setup ( klik om te vergroten)

    Als ze nu maar opties konden toevoegen voor andere dingen die storend zijn na de installatie, zoals pagina's vergrendelen in het geheugen, de standaardkostendrempel voor parallellisme wijzigen, opstarttraceervlaggen specificeren (zoals 3226!), suboptimale instellingen voor energiebeheer benadrukken en inschakelen Beschikbaarheidsgroepen rechtstreeks in plaats van Configuration Manager achteraf te gebruiken. En misschien kunnen ze die vervelende waarschuwing over de firewall verwijderen; het is altijd hetzelfde en, in ieder geval voor mij, is het in geen enkel scenario zinvol of nuttig geweest.

Mist

  • Ze wijken nog steeds niet af van de limiet van 128 GB voor de standaardversie , ondanks vele verzoeken (zoals deze van Erik Darling). Het is niet mijn oorspronkelijke idee, en het zou licenties of handhaving niet eenvoudiger maken, maar de geheugenlimieten kunnen worden gemaakt in verhouding tot het aantal gelicentieerde cores. Op deze manier is je geheugenlimiet gebaseerd op hoeveel je hebt uitgegeven aan licenties, niet een willekeurige limiet die ergens 5 jaar geleden in een vergaderruimte is besloten.

    Brent Ozar (@BrentO) sprak ook over de "perfecte storm " met geheugentoekenningen in Standard Edition, en ik ben het er helemaal mee eens - ik denk dat klanten graag de premie zouden betalen van het overschakelen van CAL naar core-licenties op Standard Edition als het nu betekende dat ze meer (of zelfs al) hun geheugen zouden kunnen gebruiken.
  • Voor geheugen geoptimaliseerde TempDB is alleen voor de Enterprise-editie , terwijl andere In-Memory Database-technologieën, zoals Memory-Optimized Tables en Hybrid Buffer Pool, beschikbaar zijn in Standard Edition. Ik heb het gevoel dat deze functie een soort hybride is tussen prestaties en beschikbaarheid; in ieder geval meer een balans dan, laten we zeggen, UDF-inlining. Langzame functies laten mensen gewoon wachten; een overweldigde tempdb kan uw instantie bijna letterlijk uitschakelen. Ik heb ook het gevoel dat Enterprise-klanten al meer en betere hardware hebben om het probleem aan te pakken dan kleinere winkels zich kunnen veroorloven. Klanten die voor Standard Edition kiezen, hoeven niet per se de besparingen te hebben die wachten om cheques uit te schrijven.

    Een van de suggesties die ik had rond deze functie was dat er tijdens de installatie opdrachtregelargumenten en/of een UI-aanvinkvakje zouden moeten zijn om deze functie onmiddellijk na een installatie of upgrade in te schakelen. Dit zou onderbrekingen na de installatie voorkomen, aangezien de enige manier om de functie in te schakelen een herstart van de service is. De reden dat het niet standaard is ingeschakeld, is dat er werkbelastingspatronen zijn waarbij het voordeel niet duidelijk is, en sommige brekende scenario's met transacties en andere databases met voor geheugen geoptimaliseerde tabellen, dus ze willen dat u uw werkbelasting test en ervoor zorgt dat u de juiste soorten twisten observeren en dat het voordeel er is. Maar wat als ik dat al heb gedaan op een ander systeem met dezelfde werklast?

Gedachten over afscheid

Hoewel het misschien klinkt alsof ik klaag, ben ik nog steeds super enthousiast over deze versie en alles wat het te bieden heeft. Ik verwacht dat de beschikbaarheid wordt aangekondigd op zowel Ignite als PASS Summit, dus je hebt misschien de RTM-bits in je hand tegen de tijd dat je dit leest.


  1. Zijn mysql_real_escape_string() en mysql_escape_string() voldoende voor app-beveiliging?

  2. Kan geen instantie van OLE DB-providerfout maken als Windows-verificatiegebruiker

  3. Is er een verschil tussen !=en <> in Oracle Sql?

  4. Een PostgreSQL-reeks naar een veld maken (wat niet de ID van de record is)