SQL Server-gegevensbestanden in Microsoft Azure

Van toepassing op:SQL Server

SQL Server-gegevensbestanden in Microsoft Azure maakt systeemeigen ondersteuning mogelijk voor SQL Server-databasebestanden die zijn opgeslagen als blobs. Hiermee kunt u een database maken in SQL Server die on-premises of op een virtuele machine in Microsoft Azure wordt uitgevoerd met een toegewezen opslaglocatie voor uw gegevens in Microsoft Azure Blob Storage. Het vereenvoudigt ook het proces van het verplaatsen van databases tussen machines. U kunt databases loskoppelen van de ene computer en deze koppelen aan een andere computer. Daarnaast biedt het een alternatieve opslaglocatie voor uw databaseback-upbestanden door u te laten herstellen van of naar Microsoft Azure Storage. Het maakt daarom verschillende hybride oplossingen mogelijk door verschillende voordelen te bieden voor gegevensvirtualisatie, gegevensverplaatsing, beveiliging en beschikbaarheid, en eventuele eenvoudige lage kosten en onderhoud voor hoge beschikbaarheid en elastisch schalen.

Belangrijk

Het opslaan van systeemdatabases in Azure Blob Storage wordt niet aanbevolen en wordt niet ondersteund.

In dit artikel worden concepten en overwegingen geïntroduceerd die centraal staan bij het opslaan van SQL Server-gegevensbestanden in Microsoft Azure Storage Service.

Zie Zelfstudie: Microsoft Azure Blob Storage gebruiken met SQL Server-databases voor praktische praktische ervaring over het gebruik van deze functie.

Waarom SQL Server-gegevensbestanden gebruiken in Microsoft Azure?

• Eenvoudige en snelle migratievoordelen: Deze functie vereenvoudigt het migratieproces door één database tegelijk te verplaatsen tussen machines in on-premises en tussen on-premises omgevingen en cloudomgevingen zonder wijzigingen in de toepassing. Daarom ondersteunt het een incrementele migratie terwijl uw bestaande on-premises infrastructuur behouden blijft. Bovendien vereenvoudigt het hebben van toegang tot een gecentraliseerde gegevensopslag de toepassingslogica wanneer een toepassing op meerdere locaties in een on-premises omgeving moet worden uitgevoerd. In sommige gevallen moet u mogelijk snel computercentra instellen op geografisch verspreide locaties, die gegevens uit veel verschillende bronnen verzamelen. Met Azure-gegevensbestanden kunt u, in plaats van gegevens van de ene locatie naar de andere te verplaatsen, veel databases opslaan als Microsoft Azure-pagina-blobs en vervolgens Transact-SQL scripts uitvoeren om databases te maken op de lokale machines of virtuele machines.

• Voordelen van kosten en onbeperkte opslag: Met deze functie kunt u onbeperkte opslag buiten de site in Microsoft Azure hebben terwijl u gebruikmaakt van on-premises rekenresources. Wanneer u Microsoft Azure als opslaglocatie gebruikt, kunt u zich eenvoudig richten op de toepassingslogica zonder de overhead van hardwarebeheer. Als u on-premises een rekenknooppunt kwijtraakt, kunt u een nieuw knooppunt instellen zonder gegevensverplaatsing.

• Voordelen van hoge beschikbaarheid en herstel na noodgevallen: Het gebruik van SQL Server-gegevensbestanden in Microsoft Azure vereenvoudigt mogelijk de oplossingen voor hoge beschikbaarheid en herstel na noodgevallen. Als een virtuele machine in Microsoft Azure of een exemplaar van SQL Server vastloopt, kunt u uw databases in een nieuw SQL Server-exemplaar opnieuw maken door alleen koppelingen naar de blobs opnieuw tot stand te brengen.

• Beveiligingsvoordelen: Met SQL Server-gegevensbestanden in Azure kunt u een rekenproces scheiden van een opslagexemplaren. U kunt een volledig versleutelde database hebben waarbij ontsleuteling alleen op een rekenexemplaar plaatsvindt en niet op een opslagexemplaar. Met andere woorden, u kunt alle gegevens in de openbare cloud versleutelen met TDE-certificaten (Transparent Data Encryption), die fysiek van de gegevens zijn gescheiden. De TDE-sleutels kunnen worden opgeslagen in de master database, die lokaal wordt opgeslagen op uw fysiek beveiligde on-premises computer en lokaal wordt geback-upt. U kunt deze lokale sleutels gebruiken om de gegevens te versleutelen, die zich in Microsoft Azure Storage bevinden. Als uw cloudopslagaccountreferenties worden gestolen, blijven uw gegevens veilig omdat de TDE-certificaten zich altijd on-premises bevinden.

• Back-up van momentopname: Met deze functie kunt u Azure-momentopnamen gebruiken om bijna onmiddellijke back-ups en snellere herstelbewerkingen te bieden voor databasebestanden die zijn opgeslagen met behulp van Azure Blob Storage. Met deze mogelijkheid kunt u uw back-up- en herstelbeleid vereenvoudigen. Zie File-Snapshot Backups for Database Files in Azurevoor meer informatie.

Concepten en vereisten

Azure-schijven zijn compatibel met bedrijfsbrede bedrijfscontinuïteit en oplossingen voor herstel na noodgevallen. Als u uw databases rechtstreeks opslaat in blobs of in Azure Premium Files, worden de gegevens niet automatisch gekoppeld aan uw VIRTUELE machine voor infrastructuur, beheer en bewaking.

Het plaatsen van de databasebestanden op pagina-blobs is een geavanceerdere functie dan het gebruik van Azure Disks, die eenvoudig en gebruiksvriendelijk zijn.

De basisrichtlijn is het gebruik van Azure Disks, tenzij u een situatie hebt waarin u het echt moet vermijden een kopie van de gegevens voor back-ups te maken, of herstellen als een operatie waarvan de tijd afhankelijk is van de omvang van de gegevens. Voor hoge beschikbaarheid en herstel na noodgevallen is het gebruik van regelmatige back-up naar URL of beheerde back-up naar Blob Storage ook veel nuttiger dan back-ups van bestandsmomentopnamen, omdat u levenscyclusbeheer, ondersteuning voor meerdere regio's, voorlopig verwijderen en alle andere functies van blobopslag van uw back-ups krijgt.

Concepten van Azure Storage

Wanneer u de functie SQL Server-gegevensbestanden in Azure gebruikt, moet u een opslagaccount en een container in Azure maken. Vervolgens moet u een SQL Server-referentie maken, die informatie bevat over het beleid van de container, evenals een handtekening voor gedeelde toegang die nodig is voor toegang tot de container.

In Microsoft Azure vertegenwoordigt een Azure-opslagaccount het hoogste niveau van de naamruimte voor toegang tot blobs. Een opslagaccount kan een onbeperkt aantal containers bevatten, zolang de totale grootte lager is dan de opslaglimieten. Zie azure-abonnements- en servicelimieten, quota en beperkingen voor de meest recente informatie over opslaglimieten. Een container biedt een groepering van een set blobs. Alle blobs moeten zich in een container bevinden. Een account kan een onbeperkt aantal containers bevatten. Op dezelfde manier kan een container een onbeperkt aantal blobs opslaan.

Er zijn twee typen blobs die kunnen worden opgeslagen in Azure Storage: blok- en pagina-blobs. Deze functie maakt gebruik van pagina-blobs, die efficiënter werken wanneer bereiken van bytes in een bestand regelmatig worden aangepast. U hebt toegang tot blobs met de volgende URL-indeling: https://storageaccount.blob.core.windows.net/<container>/<blob>.

Opmerking

U kunt geen blok-blobs gebruiken voor SQL Server-gegevensbestanden. Gebruik pagina-blobs.

Overwegingen voor Azure-facturering

Het schatten van de kosten voor het gebruik van Azure Services is een belangrijke kwestie in het besluitvormings- en planningsproces. Wanneer u SQL Server-gegevensbestanden opslaat in Azure Storage, moet u kosten betalen die zijn gekoppeld aan opslag en transacties. Daarnaast is voor de implementatie van SQL Server-gegevensbestanden in Azure Storage elke 45 tot 60 seconden een verlenging van de blob-lease vereist. Dit resulteert ook in transactiekosten per databasebestand, zoals .mdf of .ldf. Gebruik de informatie op de pagina Met prijzen van Azure om een schatting te maken van de maandelijkse kosten die zijn gekoppeld aan het gebruik van Azure Storage en Azure Virtual Machines.

SQL Server-concepten

Azure-pagina-blobs gebruiken voor SQL Server-gegevensbestanden:

• Maak een beleid voor een container en genereer ook een Shared Access Signature (SAS).

• Maak voor elke container die wordt gebruikt door een gegevens- of logboekbestand een SQL Server-referentie waarvan de naam overeenkomt met het containerpad.

• Sla de informatie over de Azure Storage-container, de bijbehorende beleidsnaam en de SAS-sleutel op in het referentiearchief van SQL Server.

In het volgende voorbeeld wordt ervan uitgegaan dat er een Azure-opslagcontainer is gemaakt en een beleid is gemaakt met lees-, schrijf- en lijstrechten. Als u een beleid voor een container maakt, wordt een SAS-sleutel gegenereerd. Dit is veilig om niet-versleuteld in het geheugen te blijven en nodig is voor SQL Server om toegang te krijgen tot de blobbestanden in de container.

Vervang in het volgende codefragment '<your SAS key>' door de SAS-sleutel. De SAS-sleutel ziet er als 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>' uit.

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')  

Belangrijk

Als er actieve verwijzingen naar gegevensbestanden in een container zijn, mislukt het verwijderen van de bijbehorende SQL Server-referentie.

Zie Toegang tot Azure Storage-resources beheren voor meer informatie

Security

Hier volgen beveiligingsoverwegingen en -vereisten bij het opslaan van SQL Server-gegevensbestanden in Azure Storage.

• Bij het maken van een container voor Azure Blob Storage wordt u aangeraden de toegang tot privé in te stellen. Wanneer u de toegang instelt tot privégegevens, kunnen container- en blobgegevens alleen worden gelezen door de eigenaar van het Azure-account.

• Wanneer u SQL Server-databasebestanden opslaat in Azure Storage, moet u een handtekening voor gedeelde toegang gebruiken, een URI die beperkte toegangsrechten verleent aan containers, blobs, wachtrijen en tabellen. Met behulp van een handtekening voor gedeelde toegang kunt u SQL Server inschakelen voor toegang tot resources in uw opslagaccount zonder de sleutel van uw Azure-opslagaccount te delen.

• Daarnaast raden we u aan de traditionele on-premises beveiligingsprocedures voor uw databases te blijven implementeren.

Vereisten voor de installatie

De volgende vereisten zijn installatievereisten bij het opslaan van SQL Server-gegevensbestanden in Azure.

• ON-premises SQL Server: SQL Server 2016 en hoger bevatten deze functie. Zie SQL Server voor meer informatie over het downloaden van de nieuwste versie van SQL Server.

• SQL Server die wordt uitgevoerd op een virtuele Azure-machine: als u SQL Server installeert op een virtuele Azure-machine, installeert u SQL Server 2016 of werkt u uw bestaande exemplaar bij. Op dezelfde manier kunt u ook een nieuwe virtuele machine maken in Azure met behulp van de platforminstallatiekopieën van SQL Server 2016.

Beperkingen

• Vanwege de prestatiekenmerken van SQL Server-workloads worden SQL Server-gegevensbestanden geïmplementeerd als pagina-blobs in Azure Blob Storage. Andere typen blobopslag, zoals blokblobs of Azure Data Lake Storage, worden niet ondersteund.

• In de huidige versie van deze functie wordt het opslaan van FileStream-gegevens in Azure Storage niet ondersteund. U kunt FileStream-gegevens opslaan in een database die ook gegevensbestanden bevat die zijn opgeslagen in Azure Storage, maar alle FileStream-gegevensbestanden moeten worden opgeslagen in lokale opslag. Omdat de FileStream-gegevens zich in de lokale opslag moeten bevinden, kunnen deze niet worden verplaatst tussen machines met Behulp van Azure Storage. Daarom raden we u aan de traditionele technieken te blijven gebruiken om de gegevens te verplaatsen die zijn gekoppeld aan FileStream tussen verschillende computers.

• Op dit moment heeft slechts één SQL Server-exemplaar tegelijk toegang tot een bepaald databasebestand in Azure Storage. Als InstanceA online is met een actief databasebestand en exemplaarB per ongeluk wordt gestart en er ook een database is die verwijst naar hetzelfde gegevensbestand, kan de tweede instantie de database niet starten met een foutcode 5120 Unable to open the physical file "%.\*ls". Operating system error %d: "%ls".

• Alleen .mdf-, LDF- en .nDF-bestanden kunnen worden opgeslagen in Azure Storage met behulp van de functie SQL Server-gegevensbestanden in Azure.

• Wanneer u de functie SQL Server-gegevensbestanden in Azure gebruikt, wordt geo-replicatie voor uw opslagaccount niet ondersteund. Als een opslagaccount geo-gerepliceerd is en er een geo-failover is opgetreden, kan databasebeschadiging optreden.

• Zie Inleiding tot Blob Storage voor capaciteitsbeperkingen.

• Het is niet mogelijk om In-Memory OLTP-gegevens op te slaan in Blob Storage met behulp van de functie SQL Server-gegevensbestanden in Azure Storage. Dit komt doordat In-Memory OLTP afhankelijk is van FileStream en in de huidige versie van deze functie FileStream-gegevens opslaan in Azure Storage niet wordt ondersteund.

• Wanneer u SQL Server-gegevensbestanden in Azure gebruikt, voert SQL Server alle VERGELIJKINGen tussen URL's of bestandspaden uit met behulp van de sorteringsset in de master database.

• AlwaysOn-beschikbaarheidsgroepen worden ondersteund zolang u geen nieuwe databasebestanden toevoegt aan de database op de primaire replica. Als voor een databasebewerking een nieuw bestand moet worden gemaakt in de database op de primaire replica, moet u eerst beschikbaarheidsgroepen in het secundaire knooppunt uitschakelen. Voer vervolgens de databasebewerking uit op de database en maak een back-up van de database in de primaire replica. Vervolgens herstelt u de database naar de secundaire replica. Nadat u klaar bent, schakelt u AlwaysOn-beschikbaarheidsgroepen opnieuw in op het secundaire knooppunt.

  Opmerking

  AlwaysOn-failoverclusterexemplaren worden niet ondersteund bij het gebruik van de SQL Server-gegevensbestanden in de Azure-functie.

• Tijdens de normale werking gebruikt SQL Server tijdelijke leases om blobs voor opslag te reserveren met een verlenging van elke blob-lease om de 45 tot 60 seconden. Als een server vastloopt en een ander exemplaar van SQL Server dat is geconfigureerd voor het gebruik van dezelfde blobs, wordt gestart, wacht het nieuwe exemplaar maximaal 60 seconden totdat de bestaande lease op de blob verloopt. Het is mogelijk om de database aan een andere instantie te koppelen als u niet kunt wachten tot de lease binnen 60 seconden verloopt. U kunt dan de lease expliciet op de blob vrijgeven.

Ondersteuning voor hulpprogramma's en programmeerreferenties

In deze sectie wordt beschreven welke hulpprogramma's en programmeerreferentiebibliotheken kunnen worden gebruikt bij het opslaan van SQL Server-gegevensbestanden in Azure Storage.

PowerShell-ondersteuning

Gebruik PowerShell-cmdlets om SQL Server-gegevensbestanden op te slaan in de Blob Storage-service door te verwijzen naar een URL-pad voor blobopslag in plaats van een bestandspad. Toegang tot blobs met behulp van de volgende URL-indeling: https://storageaccount.blob.core.windows.net/<container>/<blob>.

Ondersteuning voor SQL Server-objecten en prestatiemeteritems

Vanaf SQL Server 2014 is er een nieuw SQL Server-object toegevoegd om te worden gebruikt met sql Server-gegevensbestanden in de Azure Storage-functie. Het nieuwe SQL Server-object wordt aangeroepen als SQL Server, HTTP_STORAGE_OBJECT en kan worden gebruikt door System Monitor om activiteiten te bewaken bij het uitvoeren van SQL Server met Azure Storage.

Ondersteuning voor SQL Server Management Studio

Met SQL Server Management Studio kunt u deze functie via verschillende dialoogvensters gebruiken. Vertegenwoordigt bijvoorbeeld https://teststorageaccnt.blob.core.windows.net/testcontainer/ het URL-pad van een opslagcontainer. U kunt dit pad zien in verschillende dialoogvensters, zoals Nieuwe database, Database bijvoegen en Database herstellen. Zie zelfstudie: Azure Blob Storage gebruiken met SQL Server-databases voor meer informatie.

SMO-ondersteuning (SQL Server Management Objects)

Wanneer u de functie SQL Server-gegevensbestanden in Azure gebruikt, worden alle SQL Server Management Objects (SMO) ondersteund. Als een SMO-object een bestandspad vereist, gebruikt u de BLOB-URL-indeling in plaats van een lokaal bestandspad, zoals https://teststorageaccnt.blob.core.windows.net/testcontainer/. Zie de SMO-programmeerhandleiding (SQL Server Management Objects) in SQL Server Books Online voor meer informatie over SQL Server Management Objects (SMO).

ondersteuning voor Transact-SQL

De toevoeging van deze functie heeft de volgende wijziging in het Transact-SQL oppervlaktegebied veroorzaakt:

• Een nieuwe int-kolom, credential_id in de systeemweergave sys.master_files. De credential_id-kolom wordt gebruikt om Azure Storage-gegevensbestanden terug te verwijzen naar sys.credentials voor de referenties die hiervoor zijn gemaakt. U kunt deze gebruiken om problemen op te lossen, zoals wanneer een referentie niet kan worden verwijderd omdat er een databasebestand in gebruik is.

Problemen met SQL Server-gegevensbestanden in Microsoft Azure oplossen

Als u fouten wilt voorkomen vanwege niet-ondersteunde functies of beperkingen, bekijkt u eerst beperkingen.

De lijst met fouten die u mogelijk krijgt bij het gebruik van de SQL Server-gegevensbestanden in Azure Storage-functie zijn als volgt.

Verificatiefouten

• Kan de referentie '%.*ls' niet verwijderen omdat deze wordt gebruikt door een actief databasebestand.
  Oplossing: Deze fout kan optreden wanneer u probeert een referentie te verwijderen die nog steeds wordt gebruikt door een actief databasebestand in Azure Storage. Als u de referentie wilt verwijderen, moet u eerst de bijbehorende blob verwijderen die dit databasebestand bevat. Als u een blob met een actieve lease wilt verwijderen, moet u eerst de lease vrijgeven.

• Shared Access Signature is niet correct aangemaakt op de container.
  Oplossing: Zorg ervoor dat u een gedeelde toegangssignatuur hebt gemaakt voor de container. Bekijk de instructies in les 2 in de zelfstudie: Azure Blob Storage gebruiken met SQL Server-databases.

• SQL Server-referentie is niet correct aangemaakt.
  Oplossing: zorg ervoor dat u Shared Access Signature hebt gebruikt voor het veld Identiteit en een geheim correct hebt gemaakt. Bekijk de instructies in les 3 in de zelfstudie: Azure Blob Storage gebruiken met SQL Server-databases.

Lease blob fouten:

• Fout bij het starten van SQL Server nadat een ander exemplaar met dezelfde blobbestanden is vastgelopen. Oplossing: Tijdens de normale werking gebruikt SQL Server tijdelijke leases om blobs voor opslag te reserveren met een verlenging van elke blob-lease om de 45 tot 60 seconden. Als een server vastloopt en een ander exemplaar van SQL Server dat is geconfigureerd voor het gebruik van dezelfde blobs, wordt gestart, wacht het nieuwe exemplaar maximaal 60 seconden totdat de bestaande lease op de blob verloopt. Als u de database wilt koppelen aan een ander exemplaar en u niet kunt wachten tot de lease binnen 60 seconden verloopt, kunt u de lease expliciet vrijgeven voor de blob om fouten bij koppelingsbewerkingen te voorkomen.

Databasefouten

Fouten bij het maken van een database Oplossing: Bekijk de instructies in les 4 in de zelfstudie: Microsoft Azure Blob Storage gebruiken met SQL Server-databases.

Fouten bij het uitvoeren van de instructie Alter Oplossing: zorg ervoor dat u de instructie Alter Database uitvoert wanneer de database online is. Wanneer u de gegevensbestanden naar Azure Storage kopieert, maakt u altijd een pagina-blob, geen blok-blob. Anders mislukt ALTER Database. Bekijk de instructies in les 7 in de zelfstudie: Microsoft Azure Blob Storage gebruiken met SQL Server-databases.

Foutcode: 5120 kan het fysieke bestand '%.*ls' niet openen. Besturingssysteemfout %d: "%ls"

Oplossing: Deze functie biedt geen ondersteuning voor meer dan één SQL Server-exemplaar dat tegelijkertijd toegang heeft tot dezelfde databasebestanden in Azure Storage. Als InstanceA online is met een actief databasebestand en als InstanceB is gestart en er ook een database is die verwijst naar hetzelfde gegevensbestand, kan de tweede instantie de database niet starten met een foutcode 5120 Unable to open the physical file "%.\*ls". Operating system error %d: "%ls".

U kunt dit probleem oplossen door eerst te bepalen of u ServerA nodig hebt voor toegang tot het databasebestand in Azure Storage of niet. Als dat niet het geval is, verwijdert u een verbinding tussen InstanceA en de databasebestanden in Azure Storage. Volg hiervoor deze stappen:

1. Stel het bestandspad van InstanceA in op een lokale map met behulp van de instructie ALTER Database.

2. Stel de database offline in InstanceA in.

3. Kopieer vervolgens databasebestanden van Azure Storage naar de lokale map in InstanceA. Dit zorgt ervoor dat InstanceA nog steeds een kopie van de database lokaal heeft.

4. Stel de database online in.

Foutcode 833 - I/O-aanvragen duren langer dan 15 seconden om te voltooien

Deze fout geeft aan dat het opslagsysteem niet kan voldoen aan de vereisten van de SQL Server-workload. Verlaag de IO-activiteit van de toepassingslaag of verhoog de doorvoermogelijkheden op de opslaglaag. Zie fout 833 voor meer informatie. Als de prestatieproblemen zich blijven voordoen, kunt u overwegen om bestanden te verplaatsen naar een andere opslaglaag, zoals Premium of UltraSSD. Zie voor SQL Server op Virtuele Azure-machines de opslagprestaties optimaliseren.

Volgende stappen

• Een database maken