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 hjälp av Azure-portalen
  • Affärskontinuitet och haveriberedskap (BCDR)
  • Säkerhet och efterlevnad
  • Intelligent databasövervakning och -underhåll
  • Dataförflyttning

Not

Microsoft Entra ID tidigare kallades Azure Active Directory (Azure AD).

Ö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 DTU-baserad inköpsmodell och vCore-baserad inköpsmodell.

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 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 skapar och hanterar jag 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).

Dessutom kan du med funktionen Long-Term Kvarhållning (LTR) hålla kvar 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 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, ger failovergrupper ett bekvämt sätt att hantera replikering och failöver 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å 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 ä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 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 Azure SQL Database Disaster Recovery 101.

Säkerhet och efterlevnad

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 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] är konfigurerade på 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 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.

Om du... SQL Database/Azure Synapse Analytics
Använd AD på SQL Server lokalt Federera AD med Microsoft Entra IDoch använd Microsoft Entra-autentisering. Med federation kan du använda enkel inloggning.
Behöver framtvinga multifaktorautentisering Kräv multifaktorautentisering som en policy via Microsofts villkorliga åtkomstoch använd Microsoft Entra multifaktorautentisering.
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.
Ha ett tekniskt krav för att använda SQL-autentisering Använda SQL-autentisering

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
  • 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 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 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.

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å

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

SQL Database-granskning

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.

Hotdetektering

Med hotdetekteringhar du möjlighet att enkelt agera på säkerhets- eller policyöverträdelser som upptäcks vid granskning. 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. 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 avsöker flera uppsättningar algoritmer som identifierar potentiella sårbarheter och SQL-injektionsattacker, samt avvikande mönster för databasåtkomst (till exempel åtkomst från en ovanlig plats eller av en okänd användare). 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 uppgifter som ligger stilla 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 Always Encrypted transparent datakryptering
Krypteringsintervall Helhetslösning Data i vila
Server kan komma åt känsliga data Nej Ja, eftersom kryptering är till för vilande data
Tillåtna T-SQL-åtgärder Likhetsjämförelse 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 datamaskning som gör att du kan begränsa exponeringen av känsliga data genom att maskera den för 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.

säkerhet på radnivå gör att du kan 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 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- 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

Diagram över alltid krypterad 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 uppfyller en rad olika regelkrav. Om du vill visa de senaste efterlevnadsstandarderna som har uppfyllts av SQL Database, besök Microsoft Trust Center och granska efterlevnadsstandarderna som är viktiga för din organisation för att se om SQL Database ingår i de efterlevnadscertifierade Azure-tjänsterna. Det är viktigt att observera att även om SQL Database är certifierat som en kompatibel tjänst, underlättar det efterlevnaden av organisationens tjänst men garanterar inte automatiskt den.

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 några veckors aktivitet att analysera och bygga upp användbara rekommendationer.

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:

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.

Skärmbild från Azure-portalen med ett övervakningsdiagram över databasens DTU.

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 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.

Skärmbild från Azure-portalen med en insikt om frågeprestanda.

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. Det är ju ändå så att samma databasmotorn driver molnet. Plattformen Azure SQL Database har inbyggd 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 dra stor nytta av intelligenta funktioner som Query Performance Insight (QPI) och Database Advisor tillsammans, så skillnaden i metod skiljer sig åt 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 ö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 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: Finjustera din databas.

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. För skillnaderna mellan, se Jämför vCore- och DTU-baserade inköpsmodeller av Azure SQL Database.

För att se till att du har rätt beräkningsstorlek kan du ö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, 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. 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 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 problem med dataintegritet. 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 vid behov köra egna integritetskontroller. 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

Skärmbild från Azure-portalen med knappen Exportera databas i en Azure SQL-databas.

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

Skärmbild från Azure-portalen med knappen Importera databas på en Azure SQL-server.

Hur synkroniserar jag data mellan SQL Database och SQL Server

Du har flera sätt att uppnå detta:

  • Data Sync – 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