SQL Server-Datendateien in Azure

SQL Server-Datendateien in Azure ermöglichen native Unterstützung für SQL Server-Datenbankdateien, die als Azure Blobs gespeichert sind. Sie können eine Datenbank in SQL Server erstellen, die lokal oder auf einem virtuellen Computer in Azure mit einem dedizierten Speicherort für Ihre Daten in Azure Blob Storage ausgeführt wird. Diese Erweiterung vereinfacht insbesondere das Verschieben von Datenbanken zwischen Computern mithilfe von Trennen- und Anfügenvorgängen. Darüber hinaus stellt sie einen alternativen Speicherort für Ihre Datenbanksicherungsdateien bereit, indem Sie es Ihnen ermöglichen, sie aus oder in Azure Storage wiederherzustellen. Daher ermöglicht es mehrere Hybridlösungen, indem mehrere Vorteile für Datenvirtualisierung, Datenverschiebung, Sicherheit und Verfügbarkeit sowie einfache niedrige Kosten und Wartung für hohe Verfügbarkeit und flexible Skalierung bereitgestellt werden.

In diesem Thema werden Konzepte und Überlegungen vorgestellt, die für das Speichern von SQL Server-Datendateien in Azure Storage Service von zentraler Bedeutung sind.

Eine praktische praktische Erfahrung zur Verwendung dieses neuen Features finden Sie im Lernprogramm: SQL Server-Datendateien im Azure Storage-Dienst.

Das folgende Diagramm zeigt, dass diese Erweiterung Ihnen das Speichern von SQL Server-Datenbankdateien als Azure-Blobs in Azure Storage ermöglicht, unabhängig davon, wo sich Ihr Server befindet.

Vorteile der Verwendung von SQL Server-Datendateien in Azure

• Einfache und schnelle Migrationsvorteile: Dieses Feature vereinfacht den Migrationsprozess, indem jeweils eine Datenbank zwischen Computern lokal und zwischen lokalen und cloudbasierten Umgebungen verschoben wird, ohne dass Sich die Anwendung ändert. Daher wird eine inkrementelle Migration unterstützt, während Ihre vorhandene lokale Infrastruktur beibehalten wird. Darüber hinaus vereinfacht der Zugriff auf einen zentralen Datenspeicher die Anwendungslogik, wenn eine Anwendung an mehreren Standorten in einer lokalen Umgebung ausgeführt werden muss. In einigen Fällen müssen Sie möglicherweise schnell Computerzentren an geografisch verteilten Standorten einrichten, die Daten aus vielen verschiedenen Quellen sammeln. Wenn Sie diese neue Erweiterung verwenden, können Sie viele Datenbanken nicht von einem Speicherort in einen anderen verschieben, sondern viele Datenbanken als Azure-Blobs speichern und dann Transact-SQL Skripts ausführen, um Datenbanken auf den lokalen Computern oder virtuellen Computern zu erstellen.

• Kosten- und unbegrenzte Speichervorteile: Mit diesem Feature können Sie unbegrenzten Off-Site-Speicher in Azure haben, während Sie lokale Computeressourcen nutzen. Wenn Sie Azure als Speicherort verwenden, können Sie sich ganz einfach auf die Anwendungslogik konzentrieren, ohne dass der Aufwand für die Hardwareverwaltung besteht. Wenn Sie einen lokalen Berechnungsknoten verlieren, können Sie einen neuen Knoten ohne Datenverschiebung einrichten.

• Vorteile für hohe Verfügbarkeit und Notfallwiederherstellung: Die Verwendung von SQL Server-Datendateien in Azure kann die Hochverfügbarkeits- und Notfallwiederherstellungslösungen vereinfachen. Wenn beispielsweise ein virtueller Computer in Azure oder eine Instanz von SQL Server abstürzt, können Sie Ihre Datenbanken auf einem neuen Computer neu erstellen, indem Sie einfach Verknüpfungen zu Azure Blobs neu einrichten.

• Sicherheitsvorteile: Mit dieser neuen Erweiterung können Sie eine Computeinstanz von einer Speicherinstanz trennen. Sie können eine vollständig verschlüsselte Datenbank mit Entschlüsselung nur für die Computeinstanz, aber nicht in einer Speicherinstanz verwenden. Mit dieser neuen Erweiterung können Sie also alle Daten in der öffentlichen Cloud mithilfe von TDE-Zertifikaten (Transparent Data Encryption) verschlüsseln, die physisch von den Daten getrennt sind. Die TDE-Schlüssel können in der Masterdatenbank gespeichert werden, die lokal auf Ihrem physisch sicheren lokalen Computer gespeichert und lokal gesichert wird. Sie können diese lokalen Schlüssel verwenden, um die Daten zu verschlüsseln, die sich in Azure Storage befinden. Wenn Ihre Anmeldeinformationen für Ihr Cloudspeicherkonto gestohlen werden, bleiben Ihre Daten weiterhin sicher, da sich die TDE-Zertifikate immer lokal befinden.

Konzepte und Anforderungen

Azure Storage-Konzepte

Wenn Sie SQL Server-Datendateien in Azure verwenden, müssen Sie ein Speicherkonto und einen Container in Azure erstellen. Anschließend müssen Sie eine SQL Server-Anmeldeinformation erstellen, die Informationen zur Richtlinie des Containers sowie eine freigegebene Zugriffssignatur enthält, die für den Zugriff auf den Container erforderlich ist.

In Azure stellt ein Speicherkonto die höchste Ebene des Namespace für den Zugriff auf Blobs dar. Ein Speicherkonto kann eine unbegrenzte Anzahl von Containern enthalten, solange ihre Gesamtgröße unter 500 TB liegt. Die neuesten Informationen zu Speichergrenzwerten finden Sie unter Azure-Abonnement- und Dienstbeschränkungen, Kontingente und Einschränkungen. Ein Container stellt eine Gruppierung einer Gruppe von Blobs bereit. Alle Blobs müssen sich in einem Container befinden. Ein Konto kann eine unbegrenzte Anzahl von Containern enthalten. Ebenso kann ein Container auch eine unbegrenzte Anzahl von Blobs speichern. Es gibt zwei Arten von Blobs, die in Azure Storage gespeichert werden können: Block- und Seitenblobs. Dieses neue Feature verwendet Seitenblobs, die bis zu 1 TB groß sein können und effizienter sind, wenn Bereiche von Bytes in einer Datei häufig geändert werden. Sie können mit dem folgenden URL-Format auf Blobs zugreifen: http://storageaccount.blob.core.windows.net/<container>/<blob>.

Überlegungen zur Azure-Abrechnung

Die Schätzung der Kosten für die Nutzung von Azure Services ist eine wichtige Angelegenheit im Entscheidungsfindungs- und Planungsprozess. Beim Speichern von SQL Server-Datendateien in Azure Storage müssen Sie Kosten für Speicher und Transaktionen bezahlen. Darüber hinaus erfordert die Implementierung von SQL Server-Datendateien in Azure Storage eine Erneuerung des Blob-Leases alle 45 bis 60 Sekunden implizit. Dies führt auch zu Transaktionskosten pro Datenbankdatei, z. B. .mdf oder LDF. Basierend auf unseren Schätzungen wären die Kosten für die Verlängerung von Leases für zwei Datenbankdateien (.mdf und LDF) etwa 2 Cent pro Monat nach dem aktuellen Preismodell. Es wird empfohlen, die Informationen auf der Azure-Preisseite zu verwenden, um die monatlichen Kosten für die Verwendung von Azure Storage- und Azure Virtual Machines zu schätzen.

SQL Server-Konzepte

Wenn Sie diese neue Erweiterung verwenden, müssen Sie die folgenden Schritte ausführen:

• Sie müssen eine Richtlinie für einen Container erstellen und auch einen SAS-Schlüssel (Shared Access Signature) generieren.

• Für jeden Container, der von einer Daten- oder Protokolldatei verwendet wird, müssen Sie eine SQL Server-Anmeldeinformation erstellen, deren Name dem Containerpfad entspricht.

• Sie müssen die Informationen zu Azure Storage-Container, dem zugehörigen Richtliniennamen und dem SAS-Schlüssel im SQL Server-Anmeldeinformationsspeicher speichern.

Im folgenden Beispiel wird davon ausgegangen, dass ein Azure Storage-Container erstellt wurde und eine Richtlinie mit Lese-, Schreib-, Listen-, Rechte erstellt wurde. Das Erstellen einer Richtlinie für einen Container generiert einen SAS-Schlüssel, der sicher ist, unverschlüsselt im Arbeitsspeicher zu bleiben und von SQL Server benötigt wird, um auf die BLOB-Dateien im Container zuzugreifen. Ersetzen Sie 'your SAS key' im folgenden Codeausschnitt durch einen Eintrag ähnlich dem folgenden: 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>' Weitere Informationen finden Sie unter Erstellen und Verwenden einer Signatur für den freigegebenen Zugriff

-- Create a credential  
CREATE CREDENTIAL [https://testdb.blob.core.windows.net/data]  
WITH IDENTITY='SHARED ACCESS SIGNATURE',  
SECRET = 'your SAS key'  
  
-- Create database with data and log files in Azure container.  
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')

Von Bedeutung

Wenn in einem Container aktive Verweise auf Datendateien vorhanden sind, schlägt der Versuch, die entsprechenden SQL Server-Anmeldeinformationen zu löschen, fehl.

Sicherheit

Im Folgenden finden Sie Sicherheitsüberlegungen und Anforderungen beim Speichern von SQL Server-Datendateien in Azure Storage.

• Beim Erstellen eines Containers für den Azure Blob Storage-Dienst wird empfohlen, den Zugriff auf "Privat" festzulegen. Wenn Sie den Zugriff auf private Container- und BLOB-Daten festlegen, können sie nur vom Azure-Kontobesitzer gelesen werden.

• Beim Speichern von SQL Server-Datenbankdateien in Azure Storage müssen Sie eine freigegebene Zugriffssignatur verwenden, einen URI, der eingeschränkte Zugriffsrechte für Container, Blobs, Warteschlangen und Tabellen gewährt. Mithilfe einer Freigegebenen Zugriffssignatur können Sie SQL Server für den Zugriff auf Ressourcen in Ihrem Speicherkonto aktivieren, ohne Ihren Azure Storage Account Key freizugeben.

• Darüber hinaus wird empfohlen, weiterhin die herkömmlichen lokalen Sicherheitspraktiken für Ihre Datenbanken zu implementieren.

Installationsvoraussetzungen

Folgende Installationsvoraussetzungen müssen beim Speichern von SQL Server-Datendateien in Azure berücksichtigt werden.

• Lokale SQL Server-Bereitstellung: Sql Server 2014-Version enthält dieses Feature. Informationen zum Herunterladen von SQL Server 2014 finden Sie unter SQL Server 2014.

• SQL Server, der auf einem virtuellen Azure-Computer ausgeführt wird: Wenn Sie SQL Server auf einem virtuellen Azure-Computer installieren, installieren Sie SQL Server 2014, oder aktualisieren Sie Ihre vorhandene Instanz. Ebenso können Sie einen neuen virtuellen Computer in Azure mithilfe des SQL Server 2014-Plattformimages erstellen. Informationen zum Herunterladen von SQL Server 2014 finden Sie unter SQL Server 2014.

Einschränkungen

• In der aktuellen Version dieses Features wird das Speichern von FileStream Daten in Azure Storage nicht unterstützt. Sie können Daten in einer integrierten lokalen Azure Storage-Datenbank speichern Filestream , jedoch keine Filestream-Daten zwischen Computern mithilfe von Azure Storage verschieben. Für FileStream Daten wird empfohlen, weiterhin die herkömmlichen Techniken zum Verschieben der Dateien (.mdf, LDF) zu verwenden, die mit Filestream zwischen verschiedenen Computern verknüpft sind.

• Derzeit unterstützt diese neue Erweiterung nicht mehr als eine SQL Server-Instanz, die gleichzeitig auf dieselben Datenbankdateien in Azure Storage zugreift. Wenn ServerA online mit einer aktiven Datenbankdatei ist und ServerB versehentlich gestartet wird und auch eine Datenbank vorhanden ist, die auf dieselbe Datendatei verweist, kann der zweite Server die Datenbank nicht mit einem Fehlercode 5120 starten, der die physische Datei "%.*ls" nicht öffnen kann. Betriebssystemfehler %d: "%ls".

• Nur .mdf-, LDF- und NDF-Dateien können in Azure Storage mithilfe der SQL Server-Datendateien in Azure-Feature gespeichert werden.

• Wenn Sie die SQL Server-Datendateien im Azure-Feature verwenden, wird die Georeplikation für Ihr Speicherkonto nicht unterstützt. Wenn ein Speicherkonto georeplikatiert ist und ein Geofailover aufgetreten ist, kann eine Datenbankbeschädigung auftreten.

• Jedes Blob kann maximal 1 TB groß sein. Dadurch wird eine Obergrenze für einzelne Datenbankdaten und Protokolldateien erstellt, die in Azure Storage gespeichert werden können.

• Es ist nicht möglich, In-Memory OLTP-Daten in Azure Blob mithilfe der SQL Server-Datendateien in Azure Storage-Feature zu speichern. Dies liegt daran, dass In-Memory OLTP eine FileStream Abhängigkeit hat und in der aktuellen Version dieses Features das Speichern FileStream von Daten in Azure Storage nicht unterstützt wird.

• Wenn SQL Server-Datendateien im Azure-Feature verwendet werden, führt SQL Server alle URL- oder Dateipfadvergleiche mithilfe des Sortierungssatzes in der master Datenbank aus.

• AlwaysOn Availability Groups werden unterstützt, solange Sie der primären Datenbank keine neuen Datenbankdateien hinzufügen. Wenn für einen Datenbankvorgang eine neue Datei in der primären Datenbank erstellt werden muss, deaktivieren Sie zuerst AlwaysOn-Verfügbarkeitsgruppen im sekundären Knoten. Führen Sie dann den Datenbankvorgang für die primäre Datenbank aus, und sichern Sie die Datenbank im primären Knoten. Stellen Sie als Nächstes die Datenbank auf den sekundären Knoten wieder her, und aktivieren Sie AlwaysOn-Verfügbarkeitsgruppen im sekundären Knoten. Beachten Sie, dass AlwaysOn-Failoverclusterinstanzen bei Verwendung der SQL Server-Datendateien in Azure-Feature nicht unterstützt werden.

• Während des normalen Vorgangs verwendet SQL Server temporäre Leases, um Blobs für den Speicher mit einer Erneuerung jedes Blob-Leases alle 45 bis 60 Sekunden zu reservieren. Wenn ein Server abstürzt und eine andere Instanz von SQL Server, die für die Verwendung der gleichen Blobs konfiguriert ist, gestartet wird, wartet die neue Instanz bis zu 60 Sekunden, bis die vorhandene Lease auf dem Blob abläuft. Wenn Sie die Datenbank an eine andere Instanz anfügen möchten und nicht warten können, bis das Leasing innerhalb von 60 Sekunden abläuft, können Sie das Leasing für das Blob explizit auflösen, um Fehler bei Anfügungsvorgängen zu vermeiden.

Unterstützung für Tools und Referenzmaterialien zur Programmierung

In diesem Abschnitt wird beschrieben, welche Tools und Programmierreferenzbibliotheken beim Speichern von SQL Server-Datendateien in Azure Storage verwendet werden können.

PowerShell-Unterstützung

In SQL Server 2014 können Sie PowerShell-Cmdlets verwenden, um SQL Server-Datendateien im Azure Blob Storage-Dienst zu speichern, indem Sie auf einen BLOB Storage-URL-Pfad anstelle eines Dateipfads verweisen. Sie können mit dem folgenden URL-Format: http://storageaccount.blob.core.windows.net/<container>/<blob> auf Blobs zugreifen.

Unterstützung von SQL Server-Objekt- und Leistungszählern

Ab SQL Server 2014 wurde ein neues SQL Server-Objekt hinzugefügt, das mit SQL Server-Datendateien in Azure Storage verwendet werden kann. Das neue SQL Server-Objekt wird als SQL Server, HTTP_STORAGE_OBJECT aufgerufen, und es kann vom Systemmonitor verwendet werden, um aktivitäten zu überwachen, wenn SQL Server mit Azure Storage ausgeführt wird.

SQL Server Management Studio-Unterstützung

MIT SQL Server Management Studio können Sie dieses Feature über mehrere Dialogfelder verwenden. Sie können beispielsweise den URL-Pfad des Speichercontainers eingeben, wie https://teststorageaccnt.blob.core.windows.net/testcontainer/ als Pfad in mehreren Dialogfenstern, wie „Neue Datenbank“, „Datenbank anfügen“ und „Datenbank wiederherstellen“. Weitere Informationen finden Sie im Lernprogramm: SQL Server-Datendateien im Azure Storage-Dienst.

Unterstützung von SQL Server-Verwaltungsobjekten

Wenn Sie die SQL Server-Datendateien in Azure verwenden, werden alle SQL Server Management Objects (SMO) unterstützt. Wenn für ein SMO-Objekt ein Dateipfad erforderlich ist, verwenden Sie das BLOB-URL-Format anstelle eines lokalen Dateipfads, z. B. https://teststorageaccnt.blob.core.windows.net/testcontainer/. Weitere Informationen zu SQL Server Management Objects (SMO) finden Sie im SQL Server Management Objects (SMO)-Programmierhandbuch in SQL Server Books Online.

Transact-SQL-Support

Dieses neue Feature hat die folgende Änderung im Transact-SQL Oberflächenbereich eingeführt:

• Eine neue Int-Spalte , credential_id, in der sys.master_files Systemansicht. Die Spalte credential_id wird verwendet, um Azure Storage-aktivierte Datendateien mit ihren erstellten Anmeldeinformationen in sys.credentials zu verknüpfen. Sie können es zur Problembehandlung verwenden: Zum Beispiel kann eine Anmeldeinformation nicht gelöscht werden, wenn in einer bestehenden Datenbankdatei auf sie zugegriffen wird.

Problembehandlung für SQL Server-Datendateien in Azure

Um Fehler aufgrund nicht unterstützter Features oder Einschränkungen zu vermeiden, überprüfen Sie zuerst die Einschränkungen.

Die Liste der Fehler, die Beim Verwenden der SQL Server-Datendateien im Azure Storage-Feature auftreten können, sind wie folgt.

Authentifizierungsfehler

• Die Anmeldeinformation "%.*ls" kann nicht entfernt werden, da sie von einer aktiven Datenbankdatei verwendet wird.
  Lösung: Möglicherweise wird dieser Fehler angezeigt, wenn Sie versuchen, eine Anmeldeinformation abzulegen, die noch von einer aktiven Datenbankdatei in Azure Storage verwendet wird. Um die Anmeldeinformationen abzulegen, müssen Sie zuerst das zugeordnete Blob löschen, das über diese Datenbankdatei verfügt. Um ein Blob mit einem aktiven Mietvertrag zu löschen, müssen Sie zuerst den Mietvertrag brechen.

• Die Signatur für den freigegebenen Zugriff wurde im Container nicht ordnungsgemäß erstellt.
  Lösung: Stellen Sie sicher, dass Sie eine Shared Access Signature (Freigegebene Zugriffssignatur) für den Container ordnungsgemäß erstellt haben. Lesen Sie die Anweisungen in Lektion 2 im Lernprogramm: SQL Server-Datendateien im Azure Storage-Dienst.

• SQL Server-Anmeldeinformationen wurden nicht ordnungsgemäß erstellt.
  Lösung: Stellen Sie sicher, dass Sie "Shared Access Signature" für das Feld "Identität " verwendet und einen geheimen Schlüssel ordnungsgemäß erstellt haben. Lesen Sie die Anweisungen in Lektion 3 im Lernprogramm: SQL Server-Datendateien im Azure Storage-Dienst.

Lease-Blob-Fehler:

• Fehler beim Versuch, SQL Server zu starten, nachdem eine andere Instanz dieselben BLOB-Dateien verwendet hat und abgestürzt ist. Lösung: Während des normalen Vorgangs verwendet SQL Server temporäre Leases, um Blobs für den Speicher mit einer Erneuerung jedes Blob-Leases alle 45 bis 60 Sekunden zu reservieren. Wenn ein Server abstürzt und eine andere Instanz von SQL Server, die für die Verwendung der gleichen Blobs konfiguriert ist, gestartet wird, wartet die neue Instanz bis zu 60 Sekunden, bis die vorhandene Lease auf dem Blob abläuft. Wenn Sie die Datenbank an eine andere Instanz anfügen möchten und nicht warten können, bis die Lease innerhalb von 60 Sekunden abläuft, können Sie die Lease für das Blob explizit unterbrechen, um Fehler in Anfügungsvorgängen zu vermeiden.

Datenbankfehler

1. Fehler beim Erstellen einer Datenbank
   Lösung: Überprüfen Sie die Anweisungen in Lektion 4 im Lernprogramm: SQL Server-Datendateien im Azure Storage-Dienst.

2. Fehler beim Ausführen der Alter-Anweisung
   Lösung: Führen Sie die Alter Database-Anweisung aus, wenn die Datenbank online ist. Erstellen Sie beim Kopieren der Datendateien in Azure Storage immer ein Seitenblob, kein Block-Blob. Andernfalls schlägt ALTER Database fehl. Lesen Sie die Anweisungen in Lektion 7 im Lernprogramm: SQL Server-Datendateien im Azure Storage-Dienst.

3. Fehlercode 5120 Kann die physische Datei "%.*ls" nicht öffnen. Betriebssystemfehler %d: "%ls"
   Lösung: Derzeit unterstützt diese neue Erweiterung nicht mehr als eine SQL Server-Instanz, die gleichzeitig auf dieselben Datenbankdateien in Azure Storage zugreift. Wenn ServerA mit einer aktiven Datenbankdatei online ist und ServerB versehentlich gestartet wird und auch eine Datenbank enthält, die auf dieselbe Datendatei verweist, kann der zweite Server die Datenbank nicht mit einem Fehlercode 5120 starten, der die physische Datei "%.*ls" nicht öffnen kann. Betriebssystemfehler %d: "%ls".

   Um dieses Problem zu beheben, ermitteln Sie zunächst, ob ServerA für den Zugriff auf die Datenbankdatei in Azure Storage erforderlich ist oder nicht. Falls nicht, entfernen Sie einfach eine Verbindung zwischen ServerA und den Datenbankdateien in Azure Storage. Gehen Sie dazu wie folgt vor:

   1. Legen Sie den Dateipfad von Server A mithilfe der ALTER Database-Anweisung auf einen lokalen Ordner fest.

   2. Legen Sie die Datenbank offline in Server A fest.

   3. Kopieren Sie dann Datenbankdateien aus Azure Storage in den lokalen Ordner in Server A. Dadurch wird sichergestellt, dass ServerA weiterhin lokal über eine Kopie der Datenbank verfügt.

   4. Stellen Sie die Datenbank online.

Siehe auch

Lernprogramm: SQL Server-Datendateien im Azure Storage-Dienst