Ny DBA i molnet – Hantera Azure SQL Database efter migrering

gäller för:Azure SQL Database

Att migrera från en självhanterad miljö till en PaaS som Azure SQL Database kan vara komplext. Den här artikeln beskriver de viktigaste funktionerna i Azure SQL Database för enkla databaser och pooldatabaser, vilket hjälper dig att hålla program tillgängliga, högpresterande, säkra och motståndskraftiga.

Grundläggande egenskaper för Azure SQL Database är:

• Databasövervakning med Azure-portalen
• Affärskontinuitet och haveriberedskap (BCDR)
• Säkerhet och efterlevnad
• Intelligent databasövervakning och -underhåll
• Dataförflyttning

Övervaka databaser med hjälp av Azure-portalen

För Azure Monitor-mått och aviseringar, inklusive rekommenderade aviseringsregler, se Övervaka Azure SQL Database med mått och aviseringar. Mer information om tjänstnivåer finns i Översikt över DTU-baserad inköpsmodell och köpmodell baserad på virtuell kärna.

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

Om du till exempel förväntar dig att arbetsbelastningen i databasen ska växa kan du välja att konfigurera en e-postavisering när databasen når 80% på 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. 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 fortsätta verksamheten om en katastrof inträffar. 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 skapar och hanterar jag säkerhetskopior i SQL Database?

Azure SQL Database säkerhetskopierar automatiskt databaser åt dig. Plattformen tar en fullständig säkerhetskopia varje vecka, en differentiell säkerhetskopia varje par timme och en loggbackup var femte minut för att säkerställa att katastrofåterställningen ä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, vilket varierar beroende på vilken tjänstnivå du väljer. Du kan återställa till valfri tidpunkt inom den här kvarhållningsperioden med hjälp av Point in Time Recovery (PITR).

Dessutom kan du med funktionen för långsiktig kvarhållningssäkerhetskopiering behålla dina säkerhetskopieringsfiler i upp till 10 år och återställa data från dessa säkerhetskopior när som helst under den perioden. Databassäkerhetskopior sparas i geo-replikerad lagring för att ge 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 Affärskontinuitet i Azure SQL Database.

Hur säkerställer jag affärskontinuitet i händelse av en katastrof på datacenternivå eller en 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. För mer information och tidsplanering av geo-återställningar, se Geo-återställning för Azure SQL Database.

För verksamhetskritiska databaser erbjuder Azure SQL Database aktiv geo-replikering, som skapar en geo-replikerad sekundär kopia av din ursprungliga databas i en annan region. Om din databas till exempel ursprungligen finns i Azure-regionen Västra USA och du vill ha regional katastrofberedskap, skapar du en aktiv geo-replik av databasen från Västra USA till Östra USA. När katastrofen slår till mot västra USA kan du växla över till regionen östra USA.

Förutom aktiv geo-replikering hjälper redundansgrupper dig 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 Översikt över redundansgrupper och metodtips (Azure SQL Database).

För att uppnå motståndskraft mot fel i datacenter eller tillgänglighetszoner, säkerställ att zonredundans är aktiverad för databasen eller den elastiska poolen.

Övervaka din applikation aktivt vid en katastrof och initiera en redundansväxling till den sekundära enheten. Du kan skapa upp till fyra sådana aktiva geo-repliker i olika Azure-regioner. Det blir ännu bättre. Du kan också få åtkomst till dessa sekundära aktiva geo-repliker för endast läsbehörighet. Detta bidrar till att minska svarstiden för ett geo-distribuerat programscenario.

Hur ser haveriberedskap ut med SQL Database?

Konfiguration och hantering av katastrofåterställning kan göras med bara några få steg i Azure SQL Database när du använder aktiv geo-replikering eller failover-grupper. 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 efterlevnad

Säkerhet i SQL Database är tillgängligt på databasnivå och på plattformsnivå. Du kan styra och tillhandahålla optimal säkerhet för ditt program på följande sätt:

• Identitets- och autentisering (SQL-autentisering och autentisering med Microsoft Entra-ID).
• Övervakningsaktivitet (Granskning och hotidentifiering).
• Skydda faktiska data (transparent datakryptering [TDE] och Always Encrypted).
• Styra åtkomst till känsliga och privilegierade data (säkerhet på radnivå och dynamisk datamaskering).

Microsoft Defender for Cloud 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 på alla resurser och skapa principer baserat på dina egna krav.

Vilka användarautentiseringsmetoder erbjuds i SQL Database?

Det finns två autentiseringsmetoder i SQL Database:

• Microsoft Entra-autentisering
• SQL-autentisering

Windows-autentisering stöds inte. Microsoft Entra ID är en centraliserad identitets- och åtkomsthanteringstjänst. Microsoft Entra ID ger 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 multifaktorautentiseringoch 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 använder Active Directory lokalt kan du federera det 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.

Hur begränsar eller kontrollerar jag 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
• Tjänstslutpunkter för virtuellt nätverk
• Reserverade IP-adresser

Brandvägg

Som standard tillåts inte alla anslutningar till databaser på servern, förutom (valfritt) 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 för att Tillåta Azure-tjänster och resurser att komma åt den här 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. Om du inte vill att databasen ska vara tillgänglig för azure-IP-adresser kan du inaktivera Tillåt att Azure-tjänster och resurser får åtkomst till den här servern. Dessutom kan du konfigurera tjänstslutpunkter för virtuellt nätverk.

Med tjänstslutpunkter kan du endast exponera dina kritiska Azure-resurser för ditt eget privata virtuella nätverk i Azure. Det här alternativet eliminerar offentlig åtkomst till dina resurser. Trafiken mellan ditt virtuella nätverk till Azure finns kvar i Azure-stamnätverket. Utan tjänstslutpunkter 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.

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 serverns brandväggsinställningar. 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å?

SQL Database kommunicerar via port 1433. 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?

SQL Database-granskning

Azure 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å insikt i 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å. Mer information finns i Aktivera SQL Database-granskning.

Hotdetektering

Med hotdetektering får du möjlighet att agera på säkerhets- eller principöverträdelser som identifieras av revision. Du behöver inte vara säkerhetsexpert för att hantera potentiella hot eller överträdelser i systemet. Hotdetektering har också vissa inbyggda funktioner, som SQL-injektionsdetektering, vilket är ett vanligt sätt att attackera en databasanvändning. Hotidentifiering kör flera uppsättningar algoritmer som identifierar potentiella sårbarheter och SQL-inmatningsattacker och 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 skyddar jag 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 vilande data i data- och loggfilerna
• Dina data 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. Always Encrypted ä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. Always Encrypted krypterar känsliga kolumner i tabellen från början till slut, från obehöriga klienter till den fysiska disken.

Always Encrypted har stöd för likhetsjämförelser, så databasadministratörer 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.

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

Varje program har 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. I sådana fall måste dina känsliga data antingen maskeras 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å programskiktet. Du definierar en maskeringsregel som kan skapa ett maskeringsmönster (till exempel för att endast visa de sista fyra siffrorna i ett nationellt ID SSN: XXX-XX-0000 och maskera det mesta med X tecknet) 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 hanterar jag 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 Azure SQL Database
• Eller genom att använda Azure Key Vault som nyckelarkiv

Som standard hanteras huvudnyckeln för TDE av Azure SQL Database. Om din organisation vill ha kontroll över huvudnyckeln kan du använda Azure Key Vault som nyckelarkiv. Genom att använda Azure Key Vault tar din organisation kontroll över nyckeletablerings-, rotations- och behörighetskontroller. Rotation eller byte av typen på en TDE-huvudnyckel är snabb, eftersom den bara krypterar om DEK. 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 krypterat

Det finns också en tvånyckelhierarki i Always Encrypted – en kolumn med känsliga data krypteras av en AES 256-kolumnkrypteringsnyckel (CEK), 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:

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

Nätverkstrafiken mellan din organisation och SQL Database dirigeras vanligtvis över det offentliga nätverket. Du kan dock optimera den här sökvägen och göra den säkrare med Azure ExpressRoute. ExpressRoute utökar 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 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:

• Cloud Exchange Colocation
• Alla-till-alla
• punkt-till-punkt

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:

• Introduktion till Express Route-
• Förutsättningar
• Arbetsflöden

Är SQL Database kompatibelt med några regelkrav och hur hjälper det till med min egen organisations efterlevnad?

SQL Database uppfyller en rad olika regelkrav. Om du vill visa den senaste uppsättningen med efterlevnadskrav som SQL Database har uppfyllt, besök Microsoft Trust Center och granska de efterlevnadskrav som är viktiga för din organisation för att se om SQL Database ingår bland de kompatibla Azure-tjänsterna. Sql Database är certifierat som en kompatibel tjänst, men det underlättar 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 bör 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.). SQL Database 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 kan fortsätta 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 några veckors aktivitet att analysera och bygga upp användbara rekommendationer.

Du kan få banderollmeddelanden på din Azure SQL-server med kostnadsrekommendationer. Mer information finns i Elastiska pooler som hjälper dig att hantera och skala flera databaser i Azure SQL Database och planera och hantera kostnader för Azure SQL Database.

Hur övervakar jag prestanda och resursanvändning i SQL Database?

Du kan övervaka prestanda och resursanvändning i SQL Database med hjälp av följande metoder:

Databasövervakare

Database Watcher samlar in djupgående arbetsbelastningsövervakningsdata för att ge dig en detaljerad vy över databasens prestanda, konfiguration och hälsa. Instrumentpanelen i Azure-portalen ger en översiktsvy av din Azure SQL-miljö och en detaljerad vy över varje övervakad resurs. Data samlas in i ett centralt datalager i din Azure-prenumeration. Du kan fråga, analysera, exportera, visualisera insamlade data och integrera dem med underordnade system.

Mer information om database watcher finns i följande artiklar:

• Övervaka Azure SQL-arbetsbelastningar med databasövervakare (förhandsversion)
• Snabbstart: Skapa en bevakare för att övervaka Azure SQL (förhandsversion)
• Skapa och konfigurera en bevakare (förhandsversion)
• Database Watcher-datainsamling och datauppsättningar (förhandsversion)
• Analysera data från övervakningssensor för databaser (förhandsversion)
• Vanliga frågor och svar om Database Watcher

Azure-portalen

Azure-portalen visar en databass användning genom att välja databasen och välja 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.

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 för Azure SQL Database och Azure Synapse Analytics med azure-portalen.

Dynamiska hanteringsvyer

Du kan använda sys.dm_db_resource_stats dynamiska hanteringsvyn för att returnera historik för resursförbrukningsstatistik från den senaste timmen. Använd sys.resource_stats systemkatalogvyn för att returnera historik för de senaste 14 dagarna.

Analys av sökfrågans prestanda

Insikter om frågeprestanda gör att du kan 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- aktiveras och vara aktiv för databasen.

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: samma databasmotor driver molnet. Azure SQL Database 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 viktig information som kan hjälpa dig att felsöka det aktuella 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 övergripande prestanda i allmänhet, till exempel saknade index, 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 lider din applikation eftersom det skulle finnas många korta begäranden fram och tillbaka ("chatty") mellan applikationen och servern på ett överbelastat nätverk, och dessa resor adderas snabbt. För att förbättra prestandan i det här fallet kan du använda Batch-frågor, vilket hjälper till att minska svarstiden tur och retur och förbättra programmets prestanda.

Om du märker en försämring av databasens övergripande prestanda kan du övervaka sys.dm_db_resource_stats och sys.resource_stats dynamiska hanteringsvyer för att förstå processor-, I/O- och minnesförbrukning. Dina prestanda kan påverkas om databasen är utsvulten på resurser. 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 Finjustera databasen.

Hur ser jag till att jag använder rätt tjänstnivå och beräkningsstorlek?

SQL Database erbjuder två olika inköpsmodeller: den äldre DTU-modellen och den mer anpassningsbara köpmodellen för virtuella kärnor. Mer information finns i Jämför virtuella kärnor och DTU-baserade köpmodeller för Azure SQL Database.

Du kan övervaka din fråga och databasresursförbrukning i någon av köpmodellerna. Mer information finns i Övervaka och prestandajustering. Om du märker att dina frågeställningar/databaser konstant körs varma kan du överväga att skala upp till en högre datorkapacitet. På samma sätt kan du överväga att skala ned från den aktuella beräkningsstorleken om du inte verkar använda resurserna lika mycket under hög belastning. Du kan överväga att använda Azure Automation- för att skala dina SQL-databaser enligt ett schema.

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 kan hantera vissa typer av skadade data automatiskt och utan dataförlust. Dessa inbyggda tekniker används av tjänsten när behovet uppstår. Dina databassäkerhetskopior i tjänsten testas regelbundet genom att de återställs och körs DBCC CHECKDB på dem. 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 problem när de uppstår. Du kan också köra egna integritetskontroller efter behov. Mer information finns i Dataintegritet i SQL Database.

Dataflytt efter migrering

Hur exporterar och importerar jag 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:

  

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

  

Hur synkroniserar jag 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

Relaterat innehåll

• Övervaka och prestandajustering i Azure SQL Database och Azure SQL Managed Instance