Dela via

SQL Server-datafiler i Microsoft Azure

Gäller för:SQL Server

En dekorativ bild av datafiler i Azure.

SQL Server Data Files i Microsoft Azure möjliggör internt stöd för SQL Server-databasfiler som lagras som blobar. Det gör att du kan skapa en databas i SQL Server som körs lokalt eller på en virtuell dator i Microsoft Azure med en dedikerad lagringsplats för dina data i Microsoft Azure Blob Storage. Det förenklar också processen för att flytta databaser mellan datorer. Du kan koppla från databaser från en dator och koppla dem till en annan dator. Dessutom tillhandahåller den en alternativ lagringsplats för dina databassäkerhetskopieringsfiler genom att du kan återställa från eller till Microsoft Azure Storage. Därför möjliggör den flera hybridlösningar genom att ge flera fördelar för datavirtualisering, dataflytt, säkerhet och tillgänglighet samt eventuella enkla låga kostnader och underhåll för hög tillgänglighet och elastisk skalning.

Viktigt!

Lagring av systemdatabaser i Azure Blob Storage rekommenderas inte och stöds inte.

Den här artikeln beskriver begrepp och överväganden som är centrala för lagring av SQL Server-datafiler i Microsoft Azure Storage Service.

En praktisk praktisk erfarenhet av hur du använder den här funktionen finns i Självstudie: Använda Microsoft Azure Blob Storage med SQL Server-databaser.

Varför ska du använda SQL Server-datafiler i Microsoft Azure?

  • Enkla och snabba migreringsfördelar: Den här funktionen förenklar migreringsprocessen genom att flytta en databas i taget mellan datorer lokalt och mellan lokala miljöer och molnmiljöer utan några programändringar. Därför stöder den en inkrementell migrering samtidigt som den befintliga lokala infrastrukturen finns på plats. Dessutom förenklar åtkomsten till en centraliserad datalagring programlogik när ett program behöver köras på flera platser i en lokal miljö. I vissa fall kan du behöva snabbt konfigurera datorcentra på geografiskt spridda platser, som samlar in data från många olika källor. Med Azure Data Files kan du i stället för att flytta data från en plats till en annan lagra många databaser som Microsoft Azure-sidblobar och sedan köra Transact-SQL skript för att skapa databaser på lokala datorer eller virtuella datorer.

  • Kostnads- och obegränsade lagringsfördelar: Med den här funktionen kan du ha obegränsad lagring utanför platsen i Microsoft Azure samtidigt som du använder lokala beräkningsresurser. När du använder Microsoft Azure som lagringsplats kan du enkelt fokusera på programlogik utan att behöva hantera maskinvara. Om du förlorar en beräkningsnod lokalt kan du konfigurera en ny utan någon dataflytt.

  • Fördelar med hög tillgänglighet och haveriberedskap: Användning av SQL Server Data Files i Microsoft Azure-funktionen kan förenkla lösningarna för hög tillgänglighet och haveriberedskap. Om till exempel en virtuell dator i Microsoft Azure eller en instans av SQL Server kraschar kan du återskapa dina databaser i en ny SQL Server-instans genom att bara återupprätta länkar till blobarna.

  • Säkerhetsfördelar: Med SQL Server-datafiler i Azure kan du separera en beräkningsinstans från en lagringsinstans. Du kan ha en fullständigt krypterad databas med dekryptering som endast inträffar på beräkningsinstansen, men inte i en lagringsinstans. Med andra ord kan du kryptera alla data i det offentliga molnet med hjälp av transparent datakrypteringscertifikat (TDE), som är fysiskt åtskilda från data. TDE-nycklarna kan lagras i master databasen, som lagras lokalt på din fysiskt säkra lokala dator och säkerhetskopieras lokalt. Du kan använda dessa lokala nycklar för att kryptera data som finns i Microsoft Azure Storage. Om dina autentiseringsuppgifter för molnlagringskontot blir stulna förblir dina data fortfarande säkra eftersom TDE-certifikaten alltid finns lokalt.

  • Säkerhetskopiering av ögonblicksbilder: Med den här funktionen kan du använda Azure-ögonblicksbilder för att tillhandahålla nästan omedelbara säkerhetskopieringar och snabbare återställningar för databasfiler som lagras med Hjälp av Azure Blob Storage. Med den här funktionen kan du förenkla säkerhetskopierings- och återställningsprinciperna. Mer information finns i File-Snapshot Backups for Database Files i Azure.

Begrepp och krav

Azure-diskar är kompatibla med företagsomfattande lösningar för affärskontinuitet och haveriberedskap. Om du lagrar dina databaser direkt på blobar eller i Azure Premium Files associeras inte data automatiskt med den virtuella datorn för infrastruktur, hantering och övervakning.

Att placera databasfilerna på sidblobar är en mer avancerad funktion än att använda Azure Disks, som är enkla och användarvänliga.

Den grundläggande vägledningen är att använda Azure-diskar, såvida du inte har ett scenario där du verkligen behöver undvika att skapa en kopia av data för säkerhetskopior eller återställa som en operation baserad på datastorlek. För hög tillgänglighet och haveriberedskap är det också mycket mer användbart att använda vanlig säkerhetskopiering till URL eller hanterad säkerhetskopiering till Blob Storage än säkerhetskopiering av ögonblicksbilder av filer, eftersom du får livscykelhantering, stöd för flera regioner, mjuk borttagning och alla andra funktioner i bloblagring av dina säkerhetskopior.

Azure Storage-begrepp

När du använder SQL Server Data Files i Azure-funktionen måste du skapa ett lagringskonto och en container i Azure. Sedan måste du skapa en SQL Server-autentiseringsuppgift, som innehåller information om principen för containern samt en signatur för delad åtkomst som krävs för att få åtkomst till containern.

I Microsoft Azure representerar ett Azure-lagringskonto den högsta nivån i namnområdet för åtkomst till blobar. Ett lagringskonto kan innehålla ett obegränsat antal containrar, så länge deras totala storlek ligger under lagringsgränserna. Den senaste informationen om lagringsgränser finns i Azure-prenumerations- och tjänstgränser, kvoter och begränsningar. En container tillhandahåller en gruppering av en uppsättning blobar. Alla blobar måste finnas i en container. Ett konto kan innehålla ett obegränsat antal containrar. På samma sätt kan en container lagra ett obegränsat antal blobar.

Det finns två typer av blobar som kan lagras i Azure Storage: block- och sidblobar. Den här funktionen använder sidblobar, som är mer effektiva när intervall med byte i en fil ändras ofta. Du kan komma åt blobar med följande URL-format: https://storageaccount.blob.core.windows.net/<container>/<blob>.

Anmärkning

Du kan inte använda blockblobar för SQL Server-datafiler. Använd sidblobar.

Överväganden för Azure-fakturering

Att uppskatta kostnaden för att använda Azure Services är en viktig fråga i beslutsprocessen och planeringsprocessen. När du lagrar SQL Server-datafiler i Azure Storage måste du betala kostnader som är kopplade till lagring och transaktioner. Implementeringen av SQL Server Data Files i Azure Storage kräver dessutom en förnyelse av blob-lease var 45:e till 60:e sekund implicit. Detta resulterar också i transaktionskostnader per databasfil, till exempel .mdf eller .ldf. Använd informationen på sidan Azure-priser för att beräkna de månatliga kostnader som är kopplade till användningen av Azure Storage och Azure Virtual Machines.

SQL Server-begrepp

Så här använder du Azure-sidblobar för SQL Server-datafiler:

  • Skapa en princip för en container och generera även en signatur för delad åtkomst (SAS).

  • För varje container som används av en data eller en loggfil skapar du en SQL Server-autentiseringsuppgift vars namn matchar containersökvägen.

  • Lagra informationen om Azure Storage-containern, dess associerade principnamn och SAS-nyckeln i SQL Server-autentiseringsarkivet.

I följande exempel förutsätter vi att en Azure Storage-container har skapats och att en princip har skapats med läs-, skriv- och listrättigheter. När du skapar en princip i en container genereras en SAS-nyckel, vilket är säkert att hålla okrypterat i minnet och som SQL Server behöver för att komma åt blobfilerna i containern.

I följande kodfragment ersätter du '<your SAS key>' med SAS-nyckeln. SAS-nyckeln ser ut som 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>'.

CREATE CREDENTIAL [https://testdb.blob.core.windows.net/data]  
WITH IDENTITY='SHARED ACCESS SIGNATURE',  
SECRET = '<your SAS key>'  
  
CREATE DATABASE testdb   
ON  
( NAME = testdb_dat,  
    FILENAME = 'https://testdb.blob.core.windows.net/data/TestData.mdf' )  
 LOG ON  
( NAME = testdb_log,  
    FILENAME =  'https://testdb.blob.core.windows.net/data/TestLog.ldf')

Viktigt!

Om det finns några aktiva referenser till datafiler i en container misslyckas försöken att ta bort motsvarande SQL Server-autentiseringsuppgifter.

Mer information finns i Hantera åtkomst till Azure Storage-resurser

Security

Följande är säkerhetsöverväganden och krav vid lagring av SQL Server Data Files i Azure Storage.

  • När du skapar en container för Azure Blob Storage rekommenderar vi att du anger åtkomsten till privat. När du anger åtkomsten till privat kan endast container- och blobdata läsas av Azure-kontoägaren.

  • När du lagrar SQL Server-databasfiler i Azure Storage måste du använda en signatur för delad åtkomst, en URI som ger begränsad åtkomstbehörighet till containrar, blobbar, köer och tabeller. Genom att använda en signatur för delad åtkomst kan du aktivera SQL Server för åtkomst till resurser i ditt lagringskonto utan att dela din Azure Storage-kontonyckel.

  • Dessutom rekommenderar vi att du fortsätter att implementera de traditionella lokala säkerhetsrutinerna för dina databaser.

Krav för installation

Följande är installationskraven när du lagrar SQL Server Data Files i Azure.

  • SQL Server lokalt: SQL Server 2016 och senare inkluderar den här funktionen. Information om hur du laddar ned den senaste versionen av SQL Server finns i SQL Server.

  • SQL Server som körs på en virtuell Azure-dator: Om du installerar SQL Server på en virtuell Azure-dator installerar du SQL Server 2016 eller uppdaterar din befintliga instans. På samma sätt kan du också skapa en ny virtuell dator i Azure med sql Server 2016-plattformsbild.

Begränsningar

  • På grund av prestandaegenskaperna för SQL Server-arbetsbelastningar implementeras SQL Server-datafiler som sidblobar i Azure Blob Storage. Andra typer av bloblagring, till exempel blockblobar eller Azure Data Lake Storage , stöds inte.

  • I den aktuella versionen av den här funktionen stöds inte lagring av FileStream-data i Azure Storage. Du kan lagra FileStream-data i en databas som också innehåller datafiler som lagras i Azure Storage, men alla FileStream-datafiler måste lagras på lokal lagring. Eftersom FileStream-data måste finnas på lokal lagring kan de inte flyttas mellan datorer med Hjälp av Azure Storage. Därför rekommenderar vi att du fortsätter att använda de traditionella teknikerna för att flytta data som är associerade med FileStream mellan olika datorer.

  • För närvarande kan endast en SQL Server-instans komma åt en viss databasfil i Azure Storage samtidigt. Om InstanceA är online med en aktiv databasfil och om InstanceB startas av misstag, och den också har en databas som pekar på samma datafil, kommer den andra instansen inte att starta databasen med en felkod 5120 Unable to open the physical file "%.\*ls". Operating system error %d: "%ls".

  • Endast .mdf-, .ldf- och .ndf-filer kan lagras i Azure Storage med hjälp av SQL Server Data Files i Azure-funktionen.

  • När du använder SQL Server Data Files i Azure-funktionen stöds inte geo-replikering för ditt lagringskonto. Om ett lagringskonto är geo-replikerat och en geo-failover har inträffat kan databaskorrigeringar uppstå.

  • Kapacitetsbegränsningar finns i Introduktion till Blob Storage.

  • Det går inte att lagra In-Memory OLTP-data i Blob Storage med hjälp av SQL Server Data Files i Azure Storage-funktionen. Det beror på att In-Memory OLTP har ett beroende av FileStream och i den aktuella versionen av den här funktionen stöds inte lagring av FileStream-data i Azure Storage.

  • När du använder SQL Server Data Files i Azure-funktionen utför SQL Server alla URL- eller filsökvägsjämförelser med hjälp av sorteringsuppsättningen master i databasen.

  • AlwaysOn-tillgänglighetsgrupper stöds så länge du inte lägger till nya databasfiler i databasen på den primära repliken. Om en databasåtgärd kräver att en ny fil skapas i databasen på den primära repliken inaktiverar du först tillgänglighetsgrupper i den sekundära noden. Utför sedan databasåtgärden på databasen och säkerhetskopiera databasen i den primära repliken. Återställ sedan databasen till den sekundära repliken. När du är klar återaktiverar du AlwaysOn-tillgänglighetsgrupper i den sekundära noden.

    Anmärkning

    AlwaysOn-redundansklusterinstanser stöds inte när du använder SQL Server-datafilerna i Azure-funktionen.

  • Vid normal drift använder SQL Server tillfälliga leasingavtal för att reservera blobar för lagring med en förnyelse av varje bloblån var 45:e till 60:e sekund. Om en server kraschar och en annan instans av SQL Server som konfigurerats för att använda samma blobar startas väntar den nya instansen upp till 60 sekunder innan det befintliga lånet för blobben upphör att gälla. Om du vill koppla databasen till en annan instans och du inte kan vänta tills lånet upphör att gälla inom 60 sekunder kan du uttryckligen släppa lånet på bloben.

Stöd för verktyg och programmeringsreferenser

I det här avsnittet beskrivs vilka verktyg och programmeringsreferensbibliotek som kan användas vid lagring av SQL Server-datafiler i Azure Storage.

PowerShell-stöd

Använd PowerShell-cmdletar för att lagra SQL Server-datafiler i Blob Storage-tjänsten genom att referera till en URL-sökväg för Blob Storage i stället för en filsökväg. Få åtkomst till blobar med följande URL-format: https://storageaccount.blob.core.windows.net/<container>/<blob>.

Stöd för SQL Server-objekt- och prestandaräknare

Från och med SQL Server 2014 har ett nytt SQL Server-objekt lagts till som ska användas med SQL Server Data Files i Azure Storage-funktionen. Det nya SQL Server-objektet kallas SQL Server, HTTP_STORAGE_OBJECT och kan användas av System Monitor för att övervaka aktivitet när du kör SQL Server med Azure Storage.

Stöd för SQL Server Management Studio

Med SQL Server Management Studio kan du använda den här funktionen via flera dialogrutor. Representerar till exempel https://teststorageaccnt.blob.core.windows.net/testcontainer/ URL-sökvägen för en lagringscontainer. Du kan se den här sökvägen i flera dialogrutor, till exempel Ny databas, Bifoga databas och Återställ databas. Mer information finns i Självstudie: Använda Azure Blob Storage med SQL Server-databaser.

Stöd för SQL Server Management Objects (SMO)

När du använder SQL Server Data Files i Azure-funktionen stöds alla SQL Server Management Objects (SMO). Om ett SMO-objekt kräver en filsökväg använder du blob-URL-formatet i stället för en lokal filsökväg, till exempel https://teststorageaccnt.blob.core.windows.net/testcontainer/. Mer information om SQL Server Management Objects (SMO) finns i Programmeringsguide för SQL Server Management Objects (SMO) i SQL Server Books Online.

Transact-SQL stöd

Tillägget av den här funktionen har introducerat följande ändring i Transact-SQL yta:

  • En ny int-kolumn, credential_id, i sys.master_files systemvyn. Kolumnen credential_id används för att göra det möjligt att korsreferensa Azure Storage-datafiler tillbaka till sys.credentials för de autentiseringsuppgifter som skapats för dem. Du kan använda den för felsökning, till exempel att en autentiseringsuppgift inte kan tas bort när det finns en databasfil som använder den.

Felsökning av SQL Server Data Files i Microsoft Azure

Om du vill undvika fel på grund av funktioner eller begränsningar som inte stöds går du först igenom Begränsningar.

Listan över fel som du kan få när du använder SQL Server Data Files i Azure Storage-funktionen är följande.

Autentiseringsfel

  • Det går inte att släppa autentiseringsuppgiften%.*ls eftersom den används av en aktiv databasfil.
    Lösning: Du kan se det här felet när du försöker släppa en autentiseringsuppgift som fortfarande används av en aktiv databasfil i Azure Storage. Om du vill ta bort autentiseringsuppgifterna måste du först ta bort den associerade blob som har den här databasfilen. Om du vill ta bort en blob som har ett aktivt lån måste du först släppa lånet.

  • Signaturen för delad åtkomst har inte skapats på rätt sätt i containern.
    Lösning: Kontrollera att du har skapat en signatur för delad åtkomst på containern på rätt sätt. Läs anvisningarna i Lektion 2 i Självstudie: Använda Azure Blob Storage med SQL Server-databaser.

  • SQL Server-autentiseringsuppgifterna har inte skapats korrekt.
    Lösning: Kontrollera att du har använt Signatur för delad åtkomst för fältet Identitet och skapat en hemlighet korrekt. Läs anvisningarna i Lektion 3 i Självstudie: Använda Azure Blob Storage med SQL Server-databaser.

Låneblobfel:

  • Fel vid försök att starta SQL Server efter att en annan instans med samma blobfiler har kraschat. Lösning: Under normal drift använder SQL Server tillfälliga leaser för att reservera blobar för lagring, med förnyelse av varje bloblease var 45:e till 60:e sekund. Om en server kraschar och en annan instans av SQL Server som konfigurerats för att använda samma blobar startas väntar den nya instansen upp till 60 sekunder innan det befintliga lånet för blobben upphör att gälla. Om du vill ansluta databasen till en annan instans och du inte kan vänta tills leasingen upphör att gälla inom 60 sekunder kan du uttryckligen släppa leasingen på blobben för att undvika eventuella fel i anslutningsåtgärderna.

Databasfel

Fel vid skapande av en databas Lösning: Läs anvisningarna i Lektion 4 i Självstudie: Använda Microsoft Azure Blob Storage med SQL Server-databaser.

Fel vid körning av Alter-instruktionen Lösning: Se till att köra alter database-instruktionen när databasen är online. När du kopierar datafilerna till Azure Storage skapar du alltid en sidblob, inte en blockblob. Annars misslyckas ALTER Database. Läs anvisningarna i Lektion 7 i Självstudie: Använda Microsoft Azure Blob Storage med SQL Server-databaser.

Felkod – 5120 Det går inte att öppna den fysiska filen "%.*ls". Operativsystemfel %d: "%ls"

Lösning: Den här funktionen stöder inte mer än en SQL Server-instans som har åtkomst till samma databasfiler i Azure Storage samtidigt. Om InstanceA är online med en aktiv databasfil och om InstanceB startas och den också har en databas som pekar på samma datafil, kommer den andra instansen inte att starta databasen med en felkod 5120 Unable to open the physical file "%.\*ls". Operating system error %d: "%ls".

Lös problemet genom att först avgöra om du behöver ServerA för att komma åt databasfilen i Azure Storage eller inte. Annars tar du bort alla anslutningar mellan InstanceA och databasfilerna i Azure Storage. Gör detta genom att följa dessa steg:

  1. Ange filsökvägen för InstanceA till en lokal mapp med hjälp av ALTER Database-instruktionen.

  2. Ställ in databasen offline i InstanceA.

  3. Kopiera sedan databasfiler från Azure Storage till den lokala mappen i InstanceA. Detta säkerställer att InstanceA fortfarande har en kopia av databasen lokalt.

  4. Ställ databasen online.

Felkod 833 – I/O-begäranden tar längre tid än 15 sekunder att slutföra

Det här felet anger att lagringssystemet inte kan uppfylla kraven för SQL Server-arbetsbelastningen. Minska antingen I/O-aktiviteten från programlagret eller öka dataflödeskapaciteten på lagringsskiktet. Mer information finns i Fel 833. Om prestandaproblem kvarstår kan du överväga att flytta filer till en annan lagringsnivå, till exempel Premium eller UltraSSD. Information om SQL Server på virtuella Azure-datorer finns i optimera lagringsprestanda.

Nästa steg

  • Last updated on