Azure SQL Database er Microsofts database-as-a-service-tilbud, der tilbyder en enorm mængde fleksibilitet og sikkerhed, og som en del af Microsofts Platform-as-a-Service kan drage fordel af yderligere funktioner. Da Azure SQL Database er databasebaseret, er der nogle store forskelle, når det kommer til justering af ydeevne.
Justering af forekomsten
Mange elementer på instansniveau, som du har været vant til at konfigurere på fulde installationer, er ikke tilladt. Nogle af disse elementer omfatter:
- Indstilling af min. og maks. serverhukommelse
- Aktivering af optimering til ad hoc-arbejdsbelastninger
- Ændring af omkostningstærskel for parallelitet
- Ændring af maks. grad af parallelitet på forekomstniveau
- Optimering af tempdb med flere datafiler
- Spor flag
Bliv ikke for ked af nogle af disse. ALTER DATABASE SCOPED CONFIGURATION-sætningen tillader en hel del konfigurationsindstillinger på det individuelle databaseniveau. Dette blev introduceret med Azure SQL Database og i SQL Server begyndende med SQL Server 2016. Nogle af disse indstillinger omfatter:
- Ryd procedurecache
- Indstilling af MAXDOP til en anden værdi end nul
- Indstil estimeringsmodellen for forespørgselsoptimeringskardinalitet
- Aktiver eller deaktiver hotfixes til forespørgselsoptimering
- Aktiver eller deaktiver parametersniffing
- Aktiver eller deaktiver identitetscachen
- Aktiver eller deaktiver en kompileret planstub, der skal gemmes i cachen, når en batch kompileres for første gang.
- Aktiver eller deaktiver indsamling af eksekveringsstatistikker for native kompilerede T-SQL-moduler.
- Aktiver eller deaktiver online som standardindstillinger for DDL-sætninger, der understøtter ONLINE=ON/OFF-syntaksen.
- Aktiver eller deaktiver genoptagelig som standardindstillinger for DDL-sætninger, der understøtter RESUMABLE=ON/OFF-syntaksen.
- Aktiver eller deaktiver auto-drop-funktionen for globale midlertidige tabeller
Som du kan se på listen over scoped-konfigurationer, har du meget kontrol og præcision til at finjustere specifik adfærd for individuelle databaser. For nogle kunder kan begrænsningerne for kontrol på instansniveau have negativ indvirkning, mens andre vil se det som en fordel.
For virksomheder, der har en database pr. kunde, der har behov for fuldstændig isolering, som er indbygget i Azure SQL Database. For dem, der har brug for SQL Server-funktionerne på instansniveau, men gerne vil drage fordel af Microsofts PaaS-tilbud, er der Azure SQL Managed Instance, som er instans-omfanget. Målet der er at have 100 % overfladekompatibilitet med SQL Server; så du kan indstille min og maks serverhukommelse, aktivere optimering til adhoc-arbejdsbelastninger og ændre både MAXDOP og omkostningstærskel for parallelitet. Tempdb på en administreret forekomst har allerede flere filer, men du kan tilføje flere og øge standardstørrelsen. På mange måder føles det virkelig som den fulde installation af SQL Server.
Forespørgselsjustering
En anden forskel mellem Azure SQL Database og SQL Server er, at Query Store er aktiveret som standard i Azure SQL Database. Du kan slå Query Store fra, men så begrænser du de intelligente ydeevneværktøjer i Azure Portal, der bruger det. Query Store er en funktion, der giver indsigt i forespørgselsydeevne og planvalg. Query Store fanger også en historie med forespørgsler, planer og runtime-statistikker, så du kan gennemgå, hvad der foregår. Vil du vide, hvilken forespørgsel der har den højeste rekompileringstid, eksekveringstid, eksekveringsantal, CPU-brug, hukommelsesforbrug, de fleste fysiske læsninger/skrivninger og mere? Query Store har disse oplysninger. For SQL Server skal du aktivere denne funktion pr. database. Hvis du er ny i Query Store, har min kollega Erin Stellato et tre timers kursus om Pluralsight, der hjælper dig i gang.
Kategorien Intelligent Performance-værktøjer har fire funktioner. For det første giver ydeevneoversigten en oversigt over din samlede databaseydeevne ved at angive de 5 bedste forespørgsler efter CPU-forbrug, eventuelle anbefalinger fra automatisk tuning, tuning-aktivitet og aktuelle automatiske tuning-indstillinger. Denne landingsside giver dig et hurtigt indblik i din præstation.
For det andet vil indstillingen for præstationsanbefalinger vise eventuelle aktuelle anbefalinger for indeksoprettelse, eller hvis nogen indekser skal udgå. Hvis nogen nylige handlinger er blevet gennemført, vil du også se historikken.
For det tredje er Query Performance Insight, hvor du kan finde en dybere indsigt i dit ressourceforbrug ved at se de 5 bedste forespørgsler efter CPU, Data I/O eller Log I/O. De 5 bedste forespørgsler er farvekodede, så du hurtigt kan se procentdelen af det samlede forbrug visuelt. Du kan klikke på forespørgsels-id'et for at få flere detaljer, inklusive SQL-teksten. Der er også en lang kørende forespørgsel-fane. Jeg kan virkelig godt lide, at Microsoft har inkluderet en funktion som denne i Azure Portal uden omkostninger. Det giver værdi ved at give kunderne en portal til at se de mest stødende forespørgsler. Det, jeg finder udfordrende her, er at have en måde at se en overordnet baseline for sammenligning af dag til dag, uge til uge og forrige måned. For en hurtig analyse og overblik er Query Performance Insight dog nyttig.
Den sidste funktion i denne kategori er automatisk tuning. Det er her du kan konfigurere kraftplanen, oprette indeks og droppe indeksindstillinger. Du kan tvinge det til, fra eller vælge at arve det fra serveren. Force plan giver Azure mulighed for at vælge, hvad det mener ville være det bedste af udførelsesplanerne for regresserede forespørgsler. Denne funktion findes også i SQL Server 2017 Enterprise Edition som automatisk plankorrektion. Nogle DBA'er bliver nervøse, når de hører om de automatiske tuning-funktioner, da de frygter, at det kan erstatte behovet for DBA'er i fremtiden. Jeg kan altid godt lide at stille spørgsmålet:"Hvor meget tid bruger du hver dag på proaktivt at tune forespørgsler?". Det overvældende svar er, at folk faktisk kan bruge meget lidt tid på proaktivt at tune, og de fleste svarer, at den eneste gang, de virkelig 'tuner', er efter en kodeudgivelse, eller når brugere begynder at klage.
Ud over de indbyggede værktøjer og værdien af at bruge Query Store, er DMV'er også let tilgængelige. Glenn Berry har en hel samling af scripts kun til Azure SQL Database, som du kan bruge. En bestemt DMV, jeg vil kalde ud, er sys.dm_os_wait_stats. Dette vil trække fra serverniveauet, så hvis du virkelig vil se på ventestatistik for databaseniveauet, skal du bruge sys.dm_db_wait_stats i stedet.
Hardware – Skalering
Et andet overvejelsesområde, når man ser på ydeevne med Azure SQL Database, er den underliggende hardware. Azure SQL Database prissættes efter Database Transaction Units (DTU'er) og vCores. DTU'er er et blandet mål for CPU, hukommelse og I/O og kommer i tre niveauer; Basic, Standard og Premium. Basic er kun 5 DTU'er, Standard spænder fra 10-3.000 DTU'er, og Premium spænder fra 125-4.000 DTU'er. For de vCore-baserede niveauer har vi General Purpose og Business Critical, der spænder fra 1-80 vCores.
I DTU-modellen bør Basic overvejes til udvikling og test. Det har kun en 7-dages backup-opbevaring, så jeg ville ikke betragte det som levedygtigt for nogen produktionsdata. Standard er god til lav, medium og høj CPU-behov med moderat til lav I/O-behov. Basic og Standard tier tilbyder 2,5 IOPS pr. DTU med 5ms (læs), 10ms (skrive). Premium-niveauet er til medium til høj CPU-efterspørgsel og høj I/O og tilbyder 48 IOPS pr. DTU med 2ms (læse/skrive). Premium-niveauet har lagerplads, der er størrelsesordener hurtigere end standarden. I vCore-modellen har du Gen4-processorer, der tilbyder 7 GB RAM pr. fysisk kerne og Gen 5-processorer, der tilbyder 5,1 GB RAM pr. logisk kerne. Fra et I/O-perspektiv tilbyder General Purpose 500 IOPS pr. vCore med 7.000 max. Business Critical tilbyder 5.000 IOPS pr. kerne med 200.000 max.
Oversigt
Azure SQL Database er fantastisk til de systemer, der har brug for databaseisolering, mens Azure SQL Managed Instance er fantastisk til de miljøer, hvor du har brug for kompatibilitet på instansniveau (understøttelse af krydsdatabaseforespørgsler). Når du har brug for at tune Azure SQL Database, skal du gøre ting på databaseniveau, da indstillinger på instansniveau er off-grænser, så konfigurationsindstillinger med databaseomfang er dine finjusteringsmuligheder. Med fejlfinding af dårligt ydende forespørgsler har du nogle indbyggede værktøjer, der hjælper, inklusive Query Store, og de fleste af dine almindelige tuning-scripts vil fungere. Du kan opleve, at du stadig har brug for mere, såsom basislinjer, flere historiske data og evnen til at skabe rådgivende betingelser for at hjælpe dig med at administrere dine arbejdsbyrder. Det er her kraftfulde overvågningsløsninger som SentryOne DB Sentry kan hjælpe.
Når alt andet fejler, eller din arbejdsbyrde blot er steget forbi dine nuværende hardwareressourcer, skaler du til et højere niveau.