Dela via

Ny DBA i molnet – Hantera Azure SQL Database efter migrering

  • Artikel

Gäller för:Azure SQL Database

Att flytta från den traditionella självhanterade, självstyrda miljön till en PaaS-miljö kan verka lite överväldigande till en början. Som apputvecklare eller dba vill du veta de viktigaste funktionerna i plattformen som hjälper dig att hålla ditt program tillgängligt, högpresterande, säkert och motståndskraftigt – alltid. Den här artikeln syftar till att göra exakt det. Artikeln organiserar resurser kortfattat och ger dig vägledning om hur du bäst använder de viktigaste funktionerna i Azure SQL Database med enkla databaser och pooldatabaser för att hantera och hålla programmet igång effektivt och uppnå optimala resultat i molnet. Typisk målgrupp för den här artikeln är de som:

  • Utvärderar migreringen av sina program till Azure SQL Database – moderniserar dina program.
  • Håller på att migrera sina program – pågående migreringsscenario.
  • Har nyligen slutfört migreringen till Azure SQL Database – Ny DBA i molnet.

I den här artikeln beskrivs några av de viktigaste egenskaperna för Azure SQL Database som en plattform som du enkelt kan använda när du arbetar med enkla databaser och pooldatabaser i elastiska pooler. De är följande:

  • Övervaka databaser med Azure-portalen
  • Affärskontinuitet och haveriberedskap (BCDR)
  • Säkerhet och regelefterlevnad
  • Intelligent databasövervakning och -underhåll
  • Dataflytt

Kommentar

Microsoft Entra-ID är det nya namnet för Azure Active Directory (Azure AD). Vi uppdaterar dokumentationen just nu.

Övervaka databaser med Azure-portalen

I Azure-portalen kan du övervaka användningen av en enskild databas genom att välja databasen och klicka på diagrammet Övervakning. Det öppnar Mått-fönstret, vilket du kan ändra genom att klicka på Redigera diagram-knappen. Lägg till följande mått:

  • CPU-procent
  • DTU-procent
  • Data IO-procent
  • Databasstorlek i procent

När du har lagt till dessa mått kan du fortsätta att visa dem i diagrammet Övervakning med mer information i fönstret Mått . Alla fyra mätvärdena visar ett snittvärde för utnyttjandeprocent i förhållande till din databas DTU:er. Mer information om tjänstnivåer finns i artiklarna om DTU-baserad köpmodell och VCore-baserad köpmodell .

Service tier monitoring of database performance.

Du kan också konfigurera aviseringar på prestandamåtten. Välj knappen Lägg till avisering i fönstret Mått. Följ guiden för att konfigurera aviseringen. Du har möjlighet att avisera om måttet överskrider ett visst tröskelvärde eller om måttet faller under ett visst tröskelvärde.

Om du exempelvis förväntar dig att arbetsbelastningen på din databas kommer att öka, kan du välja att konfigurera en e-postavisering när din databas kommer upp i 80 % för något av prestandamåtten. Du kan använda detta som en tidig varning för att ta reda på när du kanske måste växla till den näst högsta beräkningsstorleken.

Prestandamåtten kan också hjälpa dig att avgöra om du kan nedgradera till en lägre beräkningsstorlek. Anta att du använder en Standard S2-databas och alla prestandamått visar att databasen i snitt inte använder mer än 10 % vid något tillfälle. Det är då troligt att databasen skulle fungera bra i Standard S1. Tänk dock på arbetsbelastningar som toppar eller fluktuerar innan du fattar beslutet att flytta till en lägre beräkningsstorlek.

Affärskontinuitet och haveriberedskap (BCDR)

Med funktioner för affärskontinuitet och haveriberedskap kan du som vanligt fortsätta verksamheten i händelse av en katastrof. Katastrofen kan vara en händelse på databasnivå (till exempel att någon av misstag släpper en viktig tabell) eller en händelse på datacenternivå (regional katastrof, till exempel en tsunami).

Hur gör jag för att skapa och hantera säkerhetskopior i SQL Database

Du skapar inte säkerhetskopior i Azure SQL Database och det beror på att du inte behöver göra det. SQL Database säkerhetskopierar automatiskt databaser åt dig, så du behöver inte längre bekymra dig om att schemalägga, ta och hantera säkerhetskopior. Plattformen tar en fullständig säkerhetskopia varje vecka, differentiell säkerhetskopiering med några timmars mellanrum och en loggsäkerhetskopia var femte minut för att säkerställa att haveriberedskapen är effektiv och att dataförlusten är minimal. Den första fullständiga säkerhetskopieringen sker så fort du skapar en databas. Dessa säkerhetskopior är tillgängliga för dig under en viss period som kallas "kvarhållningsperiod" och varierar beroende på vilken tjänstnivå du väljer. SQL Database ger dig möjlighet att återställa till valfri tidpunkt inom den här kvarhållningsperioden med hjälp av Point in Time Recovery (PITR).

Tjänstenivå Kvarhållandeperiod i dagar
Grundläggande 7
Standard 35
Premium 35

Dessutom kan du med funktionen långsiktig kvarhållning (LTR) hålla fast vid dina säkerhetskopieringsfiler under en mycket längre period, i upp till 10 år, och återställa data från dessa säkerhetskopior när som helst under den perioden. Dessutom lagras databassäkerhetskopiorna i geo-replikerad lagring för att säkerställa motståndskraft mot regionala katastrofer. Du kan också återställa dessa säkerhetskopior i valfri Azure-region när som helst inom kvarhållningsperioden. Mer information finns i Översikt över affärskontinuitet.

Hur gör jag för att säkerställa affärskontinuitet i händelse av en katastrof på datacenternivå eller regional katastrof

Dina databassäkerhetskopior lagras i geo-replikerad lagring för att säkerställa att du under en regional katastrof kan återställa säkerhetskopian till en annan Azure-region. Detta kallas geo-återställning. RPO (Mål för återställningspunkt) för geo-återställning är vanligtvis < 1 timme och ERT (uppskattad återställningstid) – några minuter till timmar.

För verksamhetskritiska databaser erbjuder Azure SQL Database aktiv geo-replikering, vilket skapar en geo-replikerad sekundär kopia av din ursprungliga databas i en annan region. Om din databas till exempel ursprungligen finns i Azure, usa, västra och du vill ha regional katastrofåterhämtning, skapar du en aktiv geo-replik av databasen i USA, västra till USA, östra. När katastrofen slår till mot USA, västra kan du redundansväxla till regionen USA, östra.

Förutom aktiv geo-replikering ger redundansgrupper ett bekvämt sätt att hantera replikering och redundans för en grupp databaser. Du kan skapa en redundansgrupp som innehåller flera databaser i samma eller olika regioner. Du kan sedan initiera en redundansväxling av alla databaser i redundansgruppen till den sekundära regionen. Mer information finns i Redundansgrupper.

För att uppnå återhämtning för datacenter- eller tillgänglighetszonfel kontrollerar du att zonredundans är aktiverat för databasen eller den elastiska poolen.

Övervaka programmet aktivt för en katastrof och initiera en redundansväxling till den sekundära. Du kan skapa upp till 4 sådana aktiva geo-repliker i olika Azure-regioner. Det blir ännu bättre. Du kan också komma åt dessa sekundära aktiva geo-repliker för skrivskyddad åtkomst. Detta är mycket praktiskt för att minska svarstiden för ett geo-distribuerat programscenario.

Hur ser haveriberedskap ut med SQL Database

Konfiguration och hantering av haveriberedskap kan göras med bara några få klick i Azure SQL Database när du använder aktiva geo-replikerings- eller redundansgrupper. Du måste fortfarande övervaka programmet och dess databas för eventuella regionala haverier och redundansväxla till den sekundära regionen för att återställa affärskontinuiteten.

Mer information finns i Haveriberedskap för Azure SQL Database 101.

Säkerhet och regelefterlevnad

SQL Database tar säkerhet och sekretess på största allvar. Säkerhet i SQL Database är tillgängligt på databasnivå och på plattformsnivå och förstås bäst när det kategoriseras i flera lager. På varje lager får du styra och ge optimal säkerhet för ditt program. Lagren är:

Microsoft Defender för molnet erbjuder centraliserad säkerhetshantering för arbetsbelastningar som körs i Azure, lokalt och i andra moln. Du kan se om viktigt SQL Database-skydd som granskning och transparent datakryptering [TDE] har konfigurerats för alla resurser och skapa principer baserat på dina egna krav.

Vilka metoder för användarautentisering erbjuds i SQL Database

Det finns två autentiseringsmetoder i SQL Database:

Windows-autentisering stöds inte. Microsoft Entra ID är en centraliserad identitets- och åtkomsthanteringstjänst. Med detta kan du enkelt ge enkel inloggning (SSO) åtkomst till personalen i din organisation. Det innebär att autentiseringsuppgifterna delas mellan Azure-tjänster för enklare autentisering.

Microsoft Entra ID stöder multifaktorautentisering och kan enkelt integreras med Windows Server Active Directory. Detta gör det också möjligt för SQL Database och Azure Synapse Analytics att erbjuda multifaktorautentisering och gästanvändarkonton i en Microsoft Entra-domän. Om du redan har en Lokal Active Directory kan du federera katalogen med Microsoft Entra-ID för att utöka din katalog till Azure.

SQL-autentisering stöder endast användarnamn och lösenord för att autentisera användare till en databas på en viss server.

Om du... SQL Database/Azure Synapse Analytics
Föredrar att inte använda Microsoft Entra-ID i Azure Använda SQL-autentisering
Använd AD på SQL Server lokalt Federera AD med Microsoft Entra-ID och använd Microsoft Entra-autentisering. Med detta kan du använda enkel inloggning.
Behöver framtvinga multifaktorautentisering Kräv multifaktorautentisering som en princip via Microsofts villkorliga åtkomst och använd Microsoft Entra multifaktorautentisering.
Ha gästkonton från Microsoft-konton (live.com, outlook.com) eller andra domäner (gmail.com) Använd universell Microsoft Entra-autentisering i SQL Database eller en dedikerad SQL-pool, som utnyttjar Microsoft Entra B2B Collaboration.
Loggas in i Windows med dina Microsoft Entra-autentiseringsuppgifter från en federerad domän Använd Microsoft Entra-integrerad autentisering.
Loggas in i Windows med autentiseringsuppgifter från en domän som inte är federerad med Azure Använd Microsoft Entra-integrerad autentisering.
Ha mellannivåtjänster som behöver ansluta till SQL Database eller Azure Synapse Analytics Använd Microsoft Entra-integrerad autentisering.

Hur gör jag för att begränsa eller kontrollera anslutningsåtkomsten till min databas

Det finns flera tekniker som du kan använda för att uppnå en optimal anslutningsorganisation för ditt program.

  • Brandväggsregler
  • VNet-tjänstslutpunkter
  • Reserverade ip-adresser

Brandvägg

En brandvägg förhindrar åtkomst till servern från en extern entitet genom att endast tillåta specifika entiteter åtkomst till servern. Som standard tillåts inte alla anslutningar till databaser på servern, förutom (valfritt 7) anslutningar som kommer in från andra Azure-tjänster. Med en brandväggsregel kan du endast öppna åtkomsten till servern till entiteter (till exempel en utvecklardator) som du godkänner genom att tillåta datorns IP-adress via brandväggen. Du kan också ange ett intervall med IP-adresser som du vill tillåta åtkomst till servern. Du kan till exempel lägga till IP-adresser för utvecklardatorer i din organisation samtidigt genom att ange ett intervall på sidan Brandväggsinställningar.

Du kan skapa brandväggsregler på servernivå eller på databasnivå. IP-brandväggsregler på servernivå kan antingen skapas med hjälp av Azure-portalen eller med SSMS. Mer information om hur du anger en brandväggsregel på servernivå och databasnivå finns i: Skapa IP-brandväggsregler i SQL Database.

Tjänstslutpunkter

Som standard är databasen konfigurerad till "Tillåt Att Azure-tjänster får åtkomst till servern", vilket innebär att alla virtuella datorer i Azure kan försöka ansluta till databasen. Dessa försök måste fortfarande autentiseras. Men om du inte vill att databasen ska vara tillgänglig för azure-IP-adresser kan du inaktivera "Tillåt Azure-tjänster att komma åt servern". Dessutom kan du konfigurera VNet-tjänstslutpunkter.

Med tjänstslutpunkter (SE) kan du endast exponera dina kritiska Azure-resurser för ditt eget privata virtuella nätverk i Azure. Genom att göra det eliminerar du i princip offentlig åtkomst till dina resurser. Trafiken mellan ditt virtuella nätverk till Azure finns kvar i Azure-stamnätverket. Utan SE får du paketroutning med tvingad tunneltrafik. Ditt virtuella nätverk tvingar Internettrafiken till din organisation och Azure Service-trafiken att gå över samma väg. Med tjänstslutpunkter kan du optimera detta eftersom paketen flödar direkt från ditt virtuella nätverk till tjänsten i Azures stamnätverk.

VNet service endpoints

Reserverade ip-adresser

Ett annat alternativ är att etablera reserverade IP-adresser för dina virtuella datorer och lägga till de specifika IP-adresserna för virtuella datorer i inställningarna för serverns brandvägg. Genom att tilldela reserverade IP-adresser sparar du problemet med att behöva uppdatera brandväggsreglerna med ändrade IP-adresser.

Vilken port ansluter jag till SQL Database på

Port 1433. SQL Database kommunicerar via den här porten. Om du vill ansluta inifrån ett företagsnätverk måste du lägga till en regel för utgående trafik i organisationens brandväggsinställningar. Som en riktlinje bör du undvika att exponera port 1433 utanför Azure-gränsen.

Hur kan jag övervaka och reglera aktivitet på min server och databas i SQL Database

Granskning av SQL Database

Med SQL Database kan du aktivera granskning för att spåra databashändelser. SQL Database-granskning registrerar databashändelser och skriver dem i en granskningsloggfil i ditt Azure Storage-konto. Granskning är särskilt användbart om du vill få insikter om potentiella säkerhets- och principöverträdelser, upprätthålla regelefterlevnad osv. Det gör att du kan definiera och konfigurera vissa kategorier av händelser som du tror behöver granskning och baserat på att du kan få förkonfigurerade rapporter och en instrumentpanel för att få en översikt över händelser som inträffar i databasen. Du kan tillämpa dessa granskningsprinciper antingen på databasnivå eller på servernivå. En guide om hur du aktiverar granskning för servern/databasen finns i: Aktivera SQL Database-granskning.

Hotidentifiering

Med hotidentifiering får du möjlighet att agera på säkerhets- eller principöverträdelser som upptäcks av granskning mycket enkelt. Du behöver inte vara säkerhetsexpert för att hantera potentiella hot eller överträdelser i systemet. Hotidentifiering har också vissa inbyggda funktioner som IDENTIFIERING av SQL-inmatning. SQL-inmatning är ett försök att ändra eller kompromettera data och ett vanligt sätt att attackera ett databasprogram i allmänhet. Hotidentifiering kör flera uppsättningar algoritmer som identifierar potentiella sårbarheter och SQL-inmatningsattacker, samt avvikande mönster för databasåtkomst (till exempel åtkomst från en ovanlig plats eller av ett okänt huvudnamn). Säkerhetsansvariga eller andra utsedda administratörer får ett e-postmeddelande om ett hot upptäcks i databasen. Varje meddelande innehåller information om misstänkt aktivitet och rekommendationer om hur du ytterligare undersöker och minimerar hotet. Information om hur du aktiverar hotidentifiering finns i: Aktivera hotidentifiering.

Hur gör jag för att skydda mina data i allmänhet i SQL Database

Kryptering ger en stark mekanism för att skydda känsliga data från inkräktare. Dina krypterade data är inte till någon nytta för inkräktaren utan dekrypteringsnyckeln. Därför lägger den till ett extra skyddslager ovanpå de befintliga säkerhetsskikten som är inbyggda i SQL Database. Det finns två aspekter för att skydda dina data i SQL Database:

  • Dina data som finns i vila i data- och loggfilerna
  • Dina data som är under flygning

I SQL Database krypteras som standard dina vilande data i data- och loggfilerna i lagringsundersystemet helt och alltid via transparent datakryptering [TDE]. Dina säkerhetskopior krypteras också. Med TDE krävs inga ändringar på programsidan som kommer åt dessa data. Krypteringen och dekrypteringen sker transparent. därav namnet. För att skydda känsliga data under flygning och i vila tillhandahåller SQL Database en funktion som heter Always Encrypted (AE). AE är en form av kryptering på klientsidan som krypterar känsliga kolumner i databasen (så att de är i chiffertext för databasadministratörer och obehöriga användare). Servern tar emot krypterade data till att börja med. Nyckeln för Always Encrypted lagras också på klientsidan, så endast auktoriserade klienter kan dekryptera de känsliga kolumnerna. Server- och dataadministratörerna kan inte se känsliga data eftersom krypteringsnycklarna lagras på klienten. AE krypterar känsliga kolumner i tabellslut till slutpunkt, från obehöriga klienter till den fysiska disken. AE stöder likhetsjämförelser i dag, så dbas kan fortsätta att köra frågor mot krypterade kolumner som en del av sina SQL-kommandon. Always Encrypted kan användas med en mängd olika alternativ för nyckelarkiv, till exempel Azure Key Vault, Windows-certifikatarkiv och lokala maskinvarusäkerhetsmoduler.

Egenskaper Alltid krypterad Transparent datakryptering
Krypteringsintervall Slutpunkt till slutpunkt Vilande data
Servern kan komma åt känsliga data Nej Ja, eftersom kryptering är till för vilande data
Tillåtna T-SQL-åtgärder Jämförelse av likhet All T-SQL-yta är tillgänglig
Appändringar som krävs för att använda funktionen Minimal Mycket minimal
Krypteringskornighet Kolumnnivå Databasnivå

Hur kan jag begränsa åtkomsten till känsliga data i min databas

Varje program har en viss mängd känsliga data i databasen som måste skyddas från att vara synliga för alla. Vissa anställda i organisationen behöver visa dessa data, men andra bör inte kunna visa dessa data. Ett exempel är lönen för anställda. En chef skulle dock behöva tillgång till löneinformationen för sina direkta rapporter, men de enskilda teammedlemmarna borde inte ha tillgång till löneinformationen för sina kamrater. Ett annat scenario är datautvecklare som kan interagera med känsliga data under utvecklingsstadier eller testning, till exempel SSN för kunder. Den här informationen behöver inte exponeras för utvecklaren igen. I sådana fall måste dina känsliga data antingen vara maskerade eller inte exponeras alls. SQL Database erbjuder två sådana metoder för att förhindra att obehöriga användare kan visa känsliga data:

Dynamisk datamaskering är en funktion för datamaskering som gör att du kan begränsa exponeringen av känsliga data genom att maskera den till icke-privilegierade användare på programnivån. Du definierar en maskeringsregel som kan skapa ett maskeringsmönster (till exempel för att endast visa de fyra sista siffrorna i ett nationellt ID SSN: XXX-XX-0000 och markera det mesta som Xs) och identifiera vilka användare som ska undantas från maskeringsregeln. Maskeringen sker direkt och det finns olika maskeringsfunktioner tillgängliga för olika datakategorier. Med dynamisk datamaskering kan du automatiskt identifiera känsliga data i databasen och använda maskering för den.

Med säkerhet på radnivå kan du styra åtkomsten på radnivå. Det innebär att vissa rader i en databastabell som baseras på användaren som kör frågan (gruppmedlemskap eller körningskontext) är dolda. Åtkomstbegränsningen görs på databasnivån i stället för på en programnivå för att förenkla applogik. Du börjar med att skapa ett filterpredikat, filtrera bort rader som inte exponeras och säkerhetsprincipen som sedan definierar vem som har åtkomst till dessa rader. Slutligen kör slutanvändaren sin fråga och, beroende på användarens behörighet, visar de antingen dessa begränsade rader eller kan inte se dem alls.

Hur gör jag för att hantera krypteringsnycklar i molnet

Det finns viktiga hanteringsalternativ för både Always Encrypted (kryptering på klientsidan) och transparent datakryptering (kryptering i vila). Vi rekommenderar att du regelbundet roterar krypteringsnycklar. Rotationsfrekvensen bör överensstämma med både dina interna organisationsbestämmelser och efterlevnadskrav.

Transparent datakryptering (TDE)

Det finns en hierarki med två nycklar i TDE – data i varje användardatabas krypteras av en symmetrisk AES-256 databas-unik databaskrypteringsnyckel (DEK), som i sin tur krypteras av en server-unik asymmetrisk RSA 2048-huvudnyckel. Huvudnyckeln kan hanteras antingen:

  • Automatiskt av plattformen – SQL Database.
  • Eller genom att använda Azure Key Vault som nyckelarkiv.

Som standard hanteras huvudnyckeln för transparent datakryptering av SQL Database-tjänsten för enkelhetens skull. Om din organisation vill ha kontroll över huvudnyckeln finns det ett alternativ för att använda Azure Key Vault](always-encrypted-azure-key-vault-configure.md) som nyckelarkiv. Genom att använda Azure Key Vault tar din organisation kontroll över nyckeletablerings-, rotations- och behörighetskontroller. Rotation eller växling av typen av en TDE-huvudnyckel är snabb eftersom den bara krypterar DEK igen. För organisationer med uppdelning av roller mellan säkerhet och datahantering kan en säkerhetsadministratör etablera nyckelmaterialet för TDE-huvudnyckeln i Azure Key Vault och tillhandahålla en Azure Key Vault-nyckelidentifierare till databasadministratören som ska användas för kryptering i vila på en server. Key Vault är utformat så att Microsoft inte ser eller extraherar några krypteringsnycklar. Du får också en centraliserad hantering av nycklar för din organisation.

Alltid krypterad

Det finns också en hierarki med två nycklar i Always Encrypted – en kolumn med känsliga data krypteras av en CEK (AES 256-column encryption key), som i sin tur krypteras av en kolumnhuvudnyckel (CMK). Klientdrivrutinerna som tillhandahålls för Always Encrypted har inga begränsningar för längden på CMK:er. CEK:s krypterade värde lagras i databasen och CMK lagras i ett betrott nyckelarkiv, till exempel Windows Certificate Store, Azure Key Vault eller en maskinvarusäkerhetsmodul.

  • Både CEK och CMK kan roteras.
  • CEK-rotation är en storlek på dataåtgärden och kan vara tidsintensiv beroende på storleken på tabellerna som innehåller de krypterade kolumnerna. Därför är det klokt att planera CEK-rotationer i enlighet med detta.
  • CMK-rotation stör dock inte databasprestanda och kan utföras med avgränsade roller.

Följande diagram visar alternativen för nyckellagring för kolumnhuvudnycklarna i Always Encrypted

Always encrypted CMK store providers

Hur kan jag optimera och skydda trafiken mellan min organisation och SQL Database

Nätverkstrafiken mellan din organisation och SQL Database dirigeras vanligtvis via det offentliga nätverket. Men om du väljer att optimera den här sökvägen och göra den säkrare kan du titta på Azure ExpressRoute. Med ExpressRoute kan du utöka företagets nätverk till Azure-plattformen via en privat anslutning. Genom att göra det går du inte över det offentliga Internet. Du får också högre säkerhets-, tillförlitlighets- och routningsoptimering som leder till lägre nätverksfördröjningar och mycket snabbare hastigheter än vad du normalt skulle uppleva via det offentliga Internet. Om du planerar att överföra en betydande del av data mellan din organisation och Azure kan användning av ExpressRoute ge kostnadsfördelar. Du kan välja mellan tre olika anslutningsmodeller för anslutningen från din organisation till Azure:

Med ExpressRoute kan du också öka bandbreddsgränsen på upp till 2 gånger så mycket som du köper utan extra kostnad. Det går också att konfigurera anslutningar mellan regioner med Hjälp av ExpressRoute. En lista över ExpressRoute-anslutningsleverantörer finns i: ExpressRoute-partner och peeringplatser. I följande artiklar beskrivs Express Route mer detaljerat:

Är SQL Database kompatibelt med alla regelkrav och hur hjälper det med min egen organisations efterlevnad

SQL Database är kompatibelt med en rad olika regelefterlevnad. Om du vill visa den senaste uppsättningen med kompatibiliteter som har uppfyllts av SQL Database går du till Microsoft Trust Center och ökar detaljnivån för de kunskaper som är viktiga för din organisation för att se om SQL Database ingår i de kompatibla Azure-tjänsterna. Det är viktigt att observera att även om SQL Database kan vara certifierat som en kompatibel tjänst, underlättar det efterlevnaden av organisationens tjänst, men garanterar den inte automatiskt.

Intelligent databasövervakning och underhåll efter migrering

När du har migrerat databasen till SQL Database vill du övervaka databasen (till exempel kontrollera hur resursanvändningen ser ut eller DBCC-kontroller) och utföra regelbundet underhåll (till exempel återskapa eller omorganisera index, statistik osv.). Lyckligtvis är SQL Database intelligent i den meningen att den använder historiska trender och registrerade mått och statistik för att proaktivt hjälpa dig att övervaka och underhålla databasen, så att ditt program alltid körs optimalt. I vissa fall kan Azure SQL Database automatiskt utföra underhållsaktiviteter beroende på konfigurationskonfigurationen. Det finns tre aspekter för att övervaka din databas i SQL Database:

  • Prestandaövervakning och optimering.
  • Säkerhetsoptimering.
  • Kostnadsoptimering.

Prestandaövervakning och optimering

Med Query Performance Insights kan du få skräddarsydda rekommendationer för din databasarbetsbelastning så att dina program alltid kan fortsätta att köras på en optimal nivå. Du kan också konfigurera den så att dessa rekommendationer tillämpas automatiskt och du inte behöver bry dig om att utföra underhållsaktiviteter. Med SQL Database Advisor kan du automatiskt implementera indexrekommendationer baserat på din arbetsbelastning – detta kallas automatisk justering. Rekommendationerna utvecklas när programarbetsbelastningen ändras för att ge dig de mest relevanta förslagen. Du får också möjlighet att manuellt granska dessa rekommendationer och tillämpa dem efter eget gottfinnande.

Säkerhetsoptimering

SQL Database ger åtgärdsbara säkerhetsrekommendationer som hjälper dig att skydda dina data och hotidentifiering för att identifiera och undersöka misstänkta databasaktiviteter som kan utgöra en potentiell tråd i databasen. Sårbarhetsbedömning är en databasgenomsöknings- och rapporteringstjänst som gör att du kan övervaka säkerhetstillståndet för dina databaser i stor skala och identifiera säkerhetsrisker och glida från en säkerhetsbaslinje som definierats av dig. Efter varje genomsökning tillhandahålls en anpassad lista över åtgärdsbara steg och reparationsskript, samt en utvärderingsrapport som kan användas för att uppfylla efterlevnadskraven.

Med Microsoft Defender för molnet identifierar du säkerhetsrekommendationerna över hela linjen och tillämpar dem snabbt.

Kostnadsoptimering

Azure SQL-plattformen analyserar användningshistoriken i databaserna på en server för att utvärdera och rekommendera alternativ för kostnadsoptimering åt dig. Den här analysen tar vanligtvis fjorton dagar att analysera och bygga upp användbara rekommendationer. Elastisk pool är ett sådant alternativ. Rekommendationen visas på portalen som en banderoll:

elastic pool recommendations

Du kan också visa den här analysen i avsnittet "Advisor":

elastic pool recommendations-advisor

Hur gör jag för att övervaka prestanda och resursanvändning i SQL Database

I SQL Database kan du använda plattformens intelligenta insikter för att övervaka prestanda och justera därefter. Du kan övervaka prestanda och resursanvändning i SQL Database med hjälp av följande metoder:

Azure Portal

Azure-portalen visar en databass användning genom att välja databasen och klicka på diagrammet i fönstret Översikt. Du kan ändra diagrammet så att det visar flera mått, inklusive CPU-procent, DTU-procent, data-I/O-procent, sessionsprocent och databasstorleksprocent.

Monitoring chart

Monitoring chart2

I det här diagrammet kan du även konfigurera aviseringar efter resurs. Med de här aviseringarna kan du svara på resursvillkor med ett e-postmeddelande, skriva till en HTTPS/HTTP-slutpunkt eller utföra en åtgärd. Mer information finns i Skapa aviseringar.

Dynamiska hanteringsvyer

Du kan köra frågor mot vyn sys.dm_db_resource_stats dynamisk hantering för att returnera historik för resursförbrukningsstatistik från den senaste timmen och sys.resource_stats systemkatalogvyn för att returnera historiken för de senaste 14 dagarna.

Query Performance Insight

Med Query Performance Insight kan du se en historik över de viktigaste resurskrävande frågorna och långvariga frågor för en specifik databas. Du kan snabbt identifiera TOP-frågor efter resursanvändning, varaktighet och körningsfrekvens. Du kan spåra frågor och identifiera regression. Den här funktionen kräver att Query Store är aktiverat och aktivt för databasen.

Query Performance Insight

Azure SQL Analytics (förhandsversion) i Azure Monitor-loggar

Med Azure Monitor-loggar kan du samla in och visualisera viktiga prestandamått för Azure SQL Database med stöd för upp till 150 000 databaser och 5 000 elastiska SQL-pooler per arbetsyta. Du kan använda den för att övervaka och ta emot meddelanden. Du kan övervaka SQL Database- och elastiska poolmått i flera Azure-prenumerationer och elastiska pooler och kan användas för att identifiera problem på varje lager i en programstack.

Jag märker prestandaproblem: Hur skiljer sig min SQL Database-felsökningsmetod från SQL Server

En stor del av de felsökningstekniker som du använder för att diagnostisera problem med fråge- och databasprestanda förblir desamma. När alla samma databasmotor driver molnet. Plattformen – Azure SQL Database har dock byggt in "intelligens". Det kan hjälpa dig att felsöka och diagnostisera prestandaproblem ännu enklare. Den kan också utföra några av dessa korrigerande åtgärder för din räkning och i vissa fall proaktivt åtgärda dem – automatiskt.

Din metod för att felsöka prestandaproblem kan ha stor nytta av intelligenta funktioner som Query Performance Insight (QPI) och Database Advisor tillsammans, och därför skiljer sig skillnaden i metodik i det avseendet – du behöver inte längre utföra det manuella arbetet med att slipa ut de viktigaste detaljerna som kan hjälpa dig att felsöka problemet. Plattformen gör det hårda arbetet åt dig. Ett exempel på detta är QPI. Med QPI kan du öka detaljnivån till frågenivån och titta på de historiska trenderna och ta reda på exakt när frågan regresserades. Database Advisor ger dig rekommendationer om saker som kan hjälpa dig att förbättra dina övergripande prestanda i allmänhet, till exempel saknade index, att släppa index, parametrisera dina frågor osv.

Med prestandafelsökning är det viktigt att identifiera om det bara är programmet eller databasen som stöder det, vilket påverkar programmets prestanda. Ofta ligger prestandaproblemet i programlagret. Det kan vara arkitekturen eller dataåtkomstmönstret. Anta till exempel att du har ett chattigt program som är känsligt för nätverksfördröjning. I det här fallet drabbas ditt program eftersom det skulle finnas många korta begäranden fram och tillbaka ("chatty") mellan programmet och servern och i ett överbelastat nätverk går dessa tur- och returresor snabbt. För att förbättra prestandan i det här fallet kan du använda Batch-frågor. Att använda batchar hjälper dig enormt eftersom dina begäranden nu bearbetas i en batch. vilket hjälper dig att minska svarstiden för tur och retur och förbättra programmets prestanda.

Om du märker en försämring av databasens övergripande prestanda kan du dessutom övervaka sys.dm_db_resource_stats och sys.resource_stats dynamiska hanteringsvyer för att förstå processor-, I/O- och minnesförbrukning. Prestandan kanske påverkades eftersom databasen är utsvulten på resurser. Det kan vara så att du kan behöva ändra beräkningsstorleken och/eller tjänstnivån baserat på de växande och krympande arbetsbelastningskraven.

En omfattande uppsättning rekommendationer för att justera prestandaproblem finns i: Justera databasen.

Hur gör jag för att se till att jag använder rätt tjänstnivå och beräkningsstorlek

SQL Database erbjuder olika tjänstnivåer Basic, Standard och Premium. Varje tjänstnivå får du en garanterad förutsägbar prestanda som är kopplad till den tjänstnivån. Beroende på din arbetsbelastning kan du ha aktivitetstoppar där resursanvändningen kan nå taket för den aktuella beräkningsstorleken som du befinner dig i. I sådana fall är det användbart att börja med att utvärdera om en justering kan hjälpa (till exempel att lägga till eller ändra ett index osv.). Om du fortfarande stöter på gränsproblem kan du överväga att flytta till en högre tjänstnivå eller beräkningsstorlek.

Tjänstenivå Vanliga användningsfall
Grundläggande Program med en handfull användare och en databas som inte har höga krav på samtidighet, skalning och prestanda.
Standard Program med stora samtidighets-, skal- och prestandakrav i kombination med låga till medelhöga I/O-krav.
Premium Program med många samtidiga användare, hög CPU/minne och höga I/O-krav. Känsliga appar med hög samtidighet, högt dataflöde och svarstid kan utnyttja Premium-nivån.

För att se till att du har rätt beräkningsstorlek kan du övervaka din förbrukning av fråge- och databasresurser på något av ovanstående sätt i "Hur gör jag för att övervaka prestanda och resursanvändning i SQL Database". Om du upptäcker att dina frågor/databaser konsekvent körs frekvent på CPU/minne osv. kan du överväga att skala upp till en högre beräkningsstorlek. På samma sätt, om du observerar att även under dina rusningstider, verkar du inte använda resurserna lika mycket; överväg att skala ned från den aktuella beräkningsstorleken.

Om du har ett SaaS-appmönster eller ett scenario för databaskonsolidering kan du överväga att använda en elastisk pool för kostnadsoptimering. Elastisk pool är ett bra sätt att uppnå databaskonsolidering och kostnadsoptimering. Mer information om hur du hanterar flera databaser med elastisk pool finns i: Hantera pooler och databaser.

Hur ofta behöver jag köra databasintegritetskontroller för min databas?

SQL Database använder vissa smarta tekniker som gör det möjligt att hantera vissa klasser av skadade data automatiskt och utan dataförlust. Dessa tekniker är inbyggda i tjänsten och utnyttjas av tjänsten när det uppstår behov. Regelbundet testas dina databassäkerhetskopior i tjänsten genom att återställa dem och köra DBCC CHECKDB på den. Om det finns problem hanterar SQL Database dem proaktivt. Automatisk sidreparation används för att åtgärda sidor som är skadade eller har dataintegritetsproblem. Databassidorna verifieras alltid med standardinställningen CHECKSUM som verifierar sidans integritet. SQL Database övervakar och granskar proaktivt databasens dataintegritet och åtgärdar dem med högsta prioritet om det uppstår problem. Utöver dessa kan du välja att eventuellt köra egna integritetskontroller efter eget beskydd. Mer information finns i Dataintegritet i SQL Database

Dataflytt efter migrering

Hur gör jag för att exportera och importera data som BACPAC-filer från SQL Database med hjälp av Azure-portalen

  • Exportera: Du kan exportera databasen i Azure SQL Database som en BACPAC-fil från Azure-portalen

    database export

  • Importera: Du kan också importera data som en BACPAC-fil till din databas i Azure SQL Database med hjälp av Azure-portalen.

    database import

Hur gör jag för att synkronisera data mellan SQL Database och SQL Server

Du har flera sätt att uppnå detta:

  • Datasynkronisering – Den här funktionen hjälper dig att synkronisera data dubbelriktade mellan flera SQL Server-databaser och SQL Database. Om du vill synkronisera med SQL Server-databaser måste du installera och konfigurera synkroniseringsagenten på en lokal dator eller en virtuell dator och öppna den utgående TCP-porten 1433.
  • Transaktionsreplikering – Med transaktionsreplikering kan du synkronisera dina data från en SQL Server-databas till Azure SQL Database med SQL Server-instansen som utgivare och Azure SQL Database som prenumerant. För tillfället stöds endast den här konfigurationen. Mer information om hur du migrerar data från en SQL Server-databas till Azure SQL med minimal stilleståndstid finns i: Använda transaktionsreplikering

Nästa steg

Läs mer om SQL Database.