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 backup varje vecka, differentiell backup var några timmar och en loggbackup var femte minut för att säkerställa att katastrofåterställningen är effektiv och dataförlusten minimerad. Den första fullständiga säkerhetskopieringen sker så fort du skapar en databas. Du kan komma åt dessa säkerhetskopior under en viss period som kallas lagringstid, vilket varierar beroende på vilken servicenivå du väljer. Du kan återställa till vilken tidpunkt som helst inom denna lagringsperiod genom att använda Point in Time Recovery (PITR).

Dessutom gör funktionen för långtidslagring av säkerhetskopior det möjligt att behålla dina säkerhetskopior i upp till 10 år och återställa data från dessa säkerhetskopior när som helst under den perioden. Azure förvarar databasbackuper i georeplikerad lagring för att ge motståndskraft mot regionala katastrofer. Du kan också återställa dessa säkerhetskopior i vilken Azure-region som helst när som helst under lagringsperioden. 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?

Lagra dina databasbackuper i geo-replikerad lagring för att säkerställa att du vid en regional katastrof kan återställa backupen till en annan Azure-region. Den här funktionen kallas geo-restore. 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.

Utöver aktiv geo-replikering hjälper failover-grupper dig att hantera replikering och failover av 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 med skrivskyddad åtkomst, vilket bidrar till att minska latensen för ett geodistribuerat applikationsscenario.

Hur ser haveriberedskap ut med SQL Database?

Du kan konfigurera din katastrofåterställningsstrategi på bara några 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

Azure SQL Database tillhandahåller säkerhet både på databasnivå och plattformsnivå. Du kan styra och tillhandahålla optimal säkerhet för din applikation genom att använda följande funktioner:

• Identitet och autentisering (SQL-autentisering och autentisering med Microsoft Entra ID).
• Övervakningsaktivitet (Granskning och hotidentifiering).
• Skydda faktiska data (transparent datakryptering [TDE] och Always Encrypted).
• Kontroll av åtkomst till känslig och privilegierad data (radsäkerhet och dynamisk datamaskering).

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

Vilka användarautentiseringsmetoder erbjuder SQL Database?

SQL Database erbjuder två autentiseringsmetoder:

• 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. Detta innebär att inloggningsuppgifterna delas mellan Azure-tjänster för enklare autentisering.

Microsoft Entra ID stöder multifaktorautentisering och kan enkelt integreras med Microsoft Entra Connect Sync. Denna integration gör det också möjligt för Azure SQL Database att erbjuda multifaktorautentisering och gästanvändarkonton inom en Microsoft Entra-domän. Om du redan använder služba 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?

För att organisera anslutningen för din applikation, använd följande tekniker:

• Brandväggsregler
• Tjänstslutpunkter för virtuellt nätverk
• Reserverade IP-adresser

Brandvägg

Som standard förbjuder den logiska SQL-servern alla anslutningar till databaser, förutom (valfritt) anslutningar som kommer in från andra Azure-tjänster. Genom att använda en brandväggsregel kan du öppna åtkomst till din server endast för enheter (till exempel en utvecklarmaskin) som du godkänner genom att tillåta datorns IP-adress genom brandväggen. Du kan också ange ett intervall av IP-adresser som du vill tillåta åtkomst till servern. Till exempel kan du lägga till IP-adresser för utvecklarmaskinen i din organisation samtidigt genom att ange ett intervall på brandväggsinställningssidan.

Du kan skapa brandväggsregler på servernivå eller på databasnivå. Du kan skapa servernivå-IP-brandväggsregler genom att använda Azure-portalen eller genom att använda 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 din databas konfigurerad att tillåta Azure-tjänster och resurser att komma åt denna server, vilket innebär att vilken virtuell maskin som helst i Azure kan försöka ansluta till din databas. 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. Genom att använda service-endpoints flödar paketen direkt från ditt virtuella nätverk till tjänsten på Azure-backbone-nätverket.

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 behöver du inte uppdatera brandväggsreglerna med ändrade IP-adresser.

Vilken port ansluter jag till SQL Database på?

Azure SQL Database kommunicerar via port 1433. För att ansluta från ett företagsnätverk måste du lägga till en utgående regel i brandväggsinställningarna i din organisation. 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. Revision är särskilt användbart om du vill få insikt i potentiella säkerhets- och policybrott, upprätthålla regelefterlevnad och mer. Den tillhandahåller förkonfigurerade rapporter och en instrumentpanel som ger dig en översikt över händelser som inträffar i din databas. Du kan definiera och konfigurera kategorierna av händelser som behöver granskas.

Du kan tillämpa dessa revisionspolicys på databasnivå eller servernivå. För mer information, se Aktivera SQL Database Auditing.

Hotdetektering

Genom att använda hotdetektering kan du agera vid säkerhets- eller policybrott som upptäcks genom 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 databasapplikation. 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 applikation har känslig data i databasen som du behöver skydda från att bli synliga för alla. Viss personal inom organisationen behöver se dessa data, men andra bör inte. I sådana fall måste du antingen maskera din känsliga data eller inte exponera den alls. SQL Database erbjuder två metoder för att förhindra att obehöriga användare ser känslig data:

• Dynamisk datamaskering är en funktion för datamaskering som du kan använda för att begränsa känslig dataexponering genom att maskera den för icke-privilegierade användare. Du definierar en maskeringsregel som skapar ett maskeringsmönster. Till exempel kan du bara visa de sista fyra siffrorna i ett nationellt ID-nummer XXX-XX-0000 och maskera resten med tecknet X . Med dynamisk datamaskering identifierar du vilka användare som är uteslutna från maskningsregeln och kan se omaskerad data. Maskeringen sker i realtid och olika maskeringsfunktioner finns tillgängliga för olika datakategorier.

• Med säkerhet på radnivå kan du styra åtkomsten på radnivå. Denna funktion döljer vissa rader i en databastabell baserat på användaren som kör frågan (gruppmedlemskap eller exekveringskontext). Åtkomstbegränsningen görs på databasnivån istället för i applikationsnivån, vilket förenklar din applogik. Du börjar med att skapa ett predikat som filtrerar bort rader som inte är exponerade. Sedan skapar du säkerhetspolicyn som definierar vem som har tillgång till dessa rader. Slutligen kör slutanvändaren sin fråga och, beroende på användarens privilegier, ser de antingen dessa begränsade rader eller kan inte se dem alls.

Hur hanterar jag krypteringsnycklar i molnet?

Både Always Encrypted (klientbaserad kryptering) och transparent datakryptering (kryptering i vila) erbjuder kundhanterade nyckelalternativ . Rotera krypteringsnycklar regelbundet. Välj en rotationsfrekvens som stämmer överens med dina interna organisationsregler och efterlevnadskrav.

Transparent Data Encryption (TDE)

TDE använder en hierarki med två nycklar. Varje användardatabass data krypteras med en symmetrisk AES-256 databasunik databaskrypteringsnyckel (DEK), som krypteras med en serverunik 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 hanterar Azure SQL Database TDE-huvudnyckeln. Om din organisation vill ha kontroll över huvudnyckeln, använd Azure Key Vault som nyckellagring. 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 roller som skiljer mellan säkerhet och datahantering kan en säkerhetsadministratör tillhandahålla nyckelmaterialet för TDE-huvudnyckeln i Azure Key Vault och tillhandahålla en Azure Key Vault-nyckelidentifierare till databasadministratören 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

Always Encrypted använder också en hierarki med två nycklar. En kolumn med känslig data krypteras med en AES 256-kolumns krypteringsnyckel (CEK), som krypteras med 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.

• Rotera både CEK och CMK.

• CEK-rotation är en storlek på dataåtgärden och kan vara tidsintensiv beroende på storleken på tabellerna som innehåller de krypterade kolumnerna. Planera CEK-rotationer därefter.

• CMK-rotation stör inte databasens prestanda och kan göras med separata 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-databasen går generellt över det publika nätverket. Du kan dock optimera denna väg och göra den säkrare genom att använda Azure ExpressRoute. ExpressRoute utökar ditt företagsnätverk till Azure-plattformen via en privat anslutning, och kringgår det publika 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 mängd 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. Du kan också konfigurera anslutning mellan regioner genom att använda ExpressRoute. En lista över ExpressRoute-anslutningsleverantörer finns i ExpressRoute-partner och peeringplatser. Följande artiklar beskriver ExpressRoute mer i detalj:

• Förutsättningar
• Arbetsflöden

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

Azure SQL Database uppfyller en rad regulatoriska krav. För att se den senaste uppsättningen av efterlevnadskrav som SQL Database uppfyller, 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 under 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

Efter att du migrerat din databas till SQL Database, övervaka databasen (till exempel kontrollera resursanvändningen eller DBCC-kontroller) och utför regelbundet underhåll (till exempel att bygga om eller omorganisera index, statistik och mer). 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

Genom att använda Query Performance Insights kan du få skräddarsydda rekommendationer för din databasarbetsbelastning så att dina applikationer 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. Genom att använda SQL Database Advisor kan du automatiskt implementera indexrekommendationer baserat på din arbetsbelastning. Denna funktion kallas Auto-Tuning. 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 handlingsbara säkerhetsrekommendationer för att hjälpa dig att säkra dina data. Den erbjuder också hotdetektering för att identifiera och undersöka misstänkta databasaktiviteter som kan utgöra ett potentiellt hot mot databasen. Sårbarhetsbedömning är en databasskanning och rapporteringstjänst som du kan använda för att övervaka säkerhetsläget i dina databaser i stor skala och identifiera säkerhetsrisker och avvikelser från en säkerhetsbaslinje som du definierar. Efter varje skanning ges en anpassad lista med handlingsbara steg och åtgärdsskript, tillsammans med en bedömningsrapport som kan hjälpa dig att uppfylla efterlevnadskraven.

Genom att använda Microsoft Defender för molnet kan du identifiera säkerhetsrekommendationer över hela linjen och snabbt tillämpa dem.

Kostnadsoptimering

Azure SQL-plattformen analyserar utnyttjandehistoriken över databaserna i en server för att utvärdera och rekommendera kostnadsoptimeringsalternativ. 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. För mer information, se Elastiska pooler 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 genom att använda 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 databasens användning när du väljer databasen och väljer diagrammet i Översiktspanelen. 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. Dessa varningar låter dig svara på resursvillkor med ett e-postmeddelande, skriva till en HTTPS/HTTP-endpoint eller utföra en åtgärd. För mer information, se Skapa aviseringar för Azure SQL Database med hjälp av 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?

De flesta felsökningstekniker du använder för att diagnostisera frågor och databasprestandaproblem är desamma som för lokal SQL Server. Azure SQL Database använder samma SQL Database Engine. Men funktioner i Azure hjälper dig att felsöka och diagnostisera prestandaproblem ännu enklare. Den kan också utföra några av dessa korrigerande åtgärder åt dig och i vissa fall proaktivt åtgärda dem automatiskt.

Ditt tillvägagångssätt för att felsöka prestandaproblem kan dra stor nytta av att använda intelligenta funktioner som Query Performance Insight (QPI) och Database Advisor. Skillnaden i metodik är att du inte längre behöver göra det manuella arbetet med att plocka fram de viktiga detaljerna som kan hjälpa dig att felsöka problemet. Plattformen gör det hårda arbetet åt dig. Ett exempel på det arbetet är QPI. Genom att använda QPI kan du borra ner ända till frågenivå och granska historiska trender för att ta reda på exakt när frågans prestanda försämrades. Databasrådgivaren ger dig rekommendationer på saker som kan hjälpa dig att förbättra din totala prestation generellt, såsom att sakna index, ta bort index, parametrisera dina frågor och mer.

Vid prestandafelsökning är det viktigt att identifiera om det bara är applikationen eller databasen som påverkar applikationens 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 blir prestandan för din applikation lidande eftersom många korta anrop går fram och tillbaka ("småpratiga") mellan applikationen och servern. På ett överbelastat nätverk ackumuleras dessa tur- och returförfrågningar 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.

Dessutom, om du märker en försämring av databasens totala prestanda, kan du övervaka sys.dm_db_resource_stats och sys.resource_stats dynamiska hanteringsvyer för att förstå CPU-, IO- 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 åtgärda prestandaproblem finns i Justera databasen.

Hur säkerställer jag att jag använder rätt servicetier 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 databaser konsekvent körs med hög belastning, överväg att skala upp till en högre beräkningsstorlek. På samma sätt, om du inte använder resurserna lika mycket under rusningstid, överväg att skala ner från nuvarande beräkningsstorlek. Du kan överväga att använda Azure Automation för att skala dina SQL-databaser enligt en tidsplan.

Om du har ett SaaS-appmönster eller ett databaskonsolideringsscenario, överväg att använda en elastisk pool för kostnadsoptimering. En elastisk pool är ett utmärkt sätt att uppnå databaskonsolidering och kostnadsoptimering. För mer information om hantering av flera databaser med en elastisk pool, se 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. Tjänsten använder dessa inbyggda tekniker när behovet uppstår. Om det uppstår problem åtgärdar SQL Database dem proaktivt. Som ett extra skyddslager kan du välja att testa backupåterställning och köra integritetskontroller. För mer information, se Data integrity in Azure SQL Database.

Automatisk sidreparation används för att fixa sidor som är korrupta eller har problem med dataintegriteten. Inställningen CHECKSUM verifierar alltid integriteten hos databassidorna. Mer information finns i Dataintegritet i SQL Database.

Dataflytt efter migrering

Hur exporterar och importerar jag data som BACPAC-filer från SQL Database genom att använda Azure-portalen?

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

  

• Import: Du kan också importera data som en BACPAC-fil till din databas i Azure SQL Database genom att använda Azure-portalen:

  

Hur synkroniserar jag data mellan SQL Database och SQL Server?

För mer information om alternativ för datasynkronisering, se Migrera till alternativa lösningar.

Relaterat innehåll

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