Clouddaten

Erste Schritte bei der Entwicklung für SQL Azure

Lynn Langit

Microsoft Windows Azure bietet mehrere Optionen für die Speicherung von Daten. Dazu zählen der Windows Azure-Speicher und SQL Azure. Sie können sich in einem bestimmten Projekt für eine oder beide Lösungen entscheiden. Windows Azure-Speicher enthält zurzeit drei Arten von Speicherstrukturen: Tabellen, Warteschlangen und Blobs.

SQL Azure ist ein relationaler Datenspeicherdienst in der Cloud. Einige der Vorteile dieser Lösung bestehen in der Möglichkeit, ein vertrautes relationales Entwicklungsmodell zu verwenden, das zahlreiche Elemente der standardmäßigen SQL Server-Sprache (T-SQL), SQL-Tools und SQL-Dienstprogramme enthält. Natürlich führt die Arbeit mit gut verstandenen relationalen Strukturen in der Cloud, wie Tabellen, Ansichten und gespeicherten Prozeduren, auch zu einer höheren Produktivität der Entwickler, wenn diese mit der neuen Plattform arbeiten. Andere Vorteile sind die geringere Notwendigkeit von Datenbankadministrationsaufgaben wie Servereinrichtung, Serverwartung und Sicherheit sowie der integrierte Support für Zuverlässigkeit, hohe Verfügbarkeit und Skalierbarkeit.

Ich werde Windows Azure-Speicher hier nicht behandeln, und die beiden Speichermodelle hier auch nicht vergleichen. Weitere Informationen zu diesen Speicheroptionen finden Sie in der Rubrik „Datenpunkte“ von Julie Lerman aus dem Juli 2010 (msdn.microsoft.com/magazine/ff796231). Beachten Sie, dass Windows Azure-Tabellen keine relationalen Tabellen sind. Der Schwerpunkt dieses Beitrags liegt auf der Erklärung der in SQL Azure enthaltenen Funktionen.

In diesem Artikel werden die Unterschiede zwischen SQL Server und SQL Azure erklärt. Sie müssen die Unterschiede in allen Einzelheiten verstehen, um Ihr aktuelles Wissen über SQL Server für die Arbeit an Projekten nutzen zu können, die SQL Azure als Datenquelle verwenden.

Wenn das Cloudcomputing neu für Sie ist, sollten Sie sich über die Grundlagen von Windows Azure informieren, bevor Sie die Lektüre dieses Artikels fortsetzen. Gut geeignet hierfür ist das MSDN Developer Cloud Center unter msdn.microsoft.com/ff380142.

Erste Schritte mit SQL Azure

Um mit SQL Azure arbeiten zu können, müssen Sie zunächst ein Konto einrichten. Wenn Sie MSDN-Abonnement sind, können Sie zu Testzwecken bis zu drei SQL Azure-Datenbanken (mit einer maximalen Größe von jeweils 1 GB) für eine Dauer von bis zu 16 Monaten verwenden (Details unter msdn.microsoft.com/subscriptions/ee461076). Um sich für ein reguläres SQL Azure-Konto anzumelden (hierfür müssen Gebühren für die Speicherung und den Datentransfer gezahlt werden), besuchen Sie microsoft.com/windowsazure/offers/.

Nach der Anmeldung für das SQL Azure-Konto können Sie beim ersten Mal am einfachsten über das Webportal unter sql.azure.com auf das Konto zugreifen. Sie müssen sich mit der Windows Live ID anmelden, die Sie mit dem Windows Azure-Konto verknüpft haben. Nach der Anmeldung können Sie die Serverinstallation erstellen und mit der Entwicklung der Anwendung beginnen.

In Abbildung 1 sehen Sie ein Beispiel für das SQL Azure Web-Verwaltungsportal. Sie sehen einen Server und die verknüpften Datenbanken. Sie werden feststellen, dass es im Webportal auch eine Registerkarte für die Verwaltung der Firewalleinstellungen für Ihre SQL Azure-Installation gibt.

Abbildung 1 Übersicht über eine SQL Azure-Datenbank

Bei der anfänglichen Erstellung der SQL Azure-Serverinstallation wird dieser eine zufällig ausgewählte Zeichenfolge als Servername zugewiesen. Zum Zeitpunkt der Erstellung des Servers richten Sie in der Regel auch den Benutzernamen für den Administrator, das Kennwort, den geografischen Standort des Servers und die Firewallregeln ein. Sie können den Standort Ihrer SQL Azure-Installation zum Zeitpunkt der Erstellung des Servers auswählen. Ihnen wird eine Liste von Standorten (Rechenzentren) angezeigt, aus der Sie auswählen können. Wenn das Front-End der Anwendung mit Windows Azure entwickelt wurde, können Sie sowohl diese als auch die SQL Azure-Installation am selben geografischen Standort einrichten, indem Sie die beiden Installation verknüpfen.

Standardmäßig kann auf den Server nicht zugegriffen werden, sodass Sie für alle Client-IPs Firewallregeln einrichten müssen. SQL Azure verwendet den Port 1433. Achten Sie darauf, dass dieser Port auch für die Clientanwendung geöffnet ist. Bei der Verbindung mit SQL Azure verwenden Sie das Format username@servername für den Benutzernamen. SQL Azure unterstützt nur die SQL Server-Authentifizierung. Die Windows-Authentifizierung wird nicht unterstützt. Multiple Active Result Set (MARS)-Verbindungen werden unterstützt.

Offene Verbindungen laufen ab, wenn sie mehr als 30 Minuten inaktiv sind. Verbindungen können auch aufgrund von über einen langen Zeitraum ausgeführten Abfragen und Transaktionen oder übermäßiger Ressourcennutzung unterbrochen werden. Bewährte Verfahren bei der Entwicklung von Anwendungen in Bezug auf Verbindungen bestehen darin, diese Verbindungen manuell zu öffnen, zu verwenden und zu schließen, Versuche zum Aufbau unterbrochener Verbindungen einzuschließen und das Caching von Verbindungen aufgrund dieses Verhaltens zu vermeiden. Weitere Details über die unterstützten Clientprotokolle für SQL Azure finden Sie im Blog von Steve Hale unter blogs.msdn.com/b/sqlnativeclient/archive/2010/02/12/using-sql-server-client-apis-with-sql-azure-vversion-1-0.aspx.

Ein anderes bewährtes Verfahren besteht in der Verschlüsselung der Verbindungszeichenfolge, um Man-In-The-Middle-Angriffe zu verhindern.

Sie werden standardmäßig mit der Masterdatenbank verbunden, wenn Sie in der Verbindungszeichenfolge keinen Datenbanknamen angeben. In SQL Azure wird die T-SQL-Anweisung USE für geänderte Datenbanken nicht unterstützt, sodass Sie in der Regel die Datenbank, mit der Sie eine Verbindung herstellen möchten, in der Verbindungszeichenfolge angeben (vorausgesetzt, Sie möchten eine Verbindung mit einer anderen als der Masterdatenbank herstellen.) Im Folgenden sehen Sie ein Beispiel für eine ADO.NET-Verbindung:

    Server=tcp:server.ctp.database.windows.net;
    Database=<databasename>;
    User ID=user@server;
    Password=password;
    Trusted_Connection=False;
    Encrypt=true;

Einrichten von Datenbanken

Nachdem der Herstellung einer Verbindung für die Installation müssen Sie eine oder mehrere Datenbanken erstellen. Sie können Datenbanken zwar mittels des SQL Azure-Portals erstellen, sollten hierfür jedoch andere Tools wie SQL Server Management Studio 2008 R2 verwenden. Standardmäßig können Sie für jede SQL Azure-Serverinstallation bis zu 149 Datenbanken erstellen. Wenn Sie mehr als 149 Datenbanken erstellen, müssen Sie sich an den Windows Azure-Business Desk wenden, um die Anzahl der möglichen Datenbanken zu erhöhen.

Bei der Erstellung einer Datenbank müssen Sie die maximale Größe auswählen. Die aktuellen Optionen für die Größe (und Berechnung) sind Web oder Business Edition. Die Web Edition ist die Standardeinstellung und unterstützt Datenbanken mit 1 GB oder 5 GB insgesamt. Die Business Edition unterstützt Datenbanken mit bis zu 50 GB in Inkrementen von 10 GB; mit anderen Worten, 10 GB, 20 GB, 30 GB, 40 GB und 50 GB.

Sie legen die Größenbeschränkung für die Datenbank bei der Erstellung mittels des Schlüsselworts MAXSIZE fest. Sie können die Größenbeschränkung oder die Edition (Web oder Business) nach der anfänglichen Erstellung mittels der Anweisung ALTER DATABASE ändern. Wenn die maximale Größe oder die Kapazitätsgrenze für die von Ihnen ausgewählte Edition erreicht wird, wird Ihnen der Fehlercode 40544 angezeigt. In der Berechnung der Datenbankgröße sind die Masterdatenbank oder Datenbankprotokolle nicht enthalten. Weitere Details zur Größe und zur Berechnung finden Sie unter microsoft.com/windowsazure/pricing/#sql.

Beachten Sie, dass Sie bei der Erstellung einer neuen SQL Azure-Datenbank tatsächlich drei Replizierungen dieser Datenbank erstellen. Dies soll eine hohe Verfügbarkeit sicherstellen. Diese Replizierungen sind für Sie vollständig transparent. Die neue Datenbank wird Ihnen als eine einzige Einheit angezeigt.

Nach der Erstellung der Datenbank können Sie schnell die Informationen für die Verbindungszeichenfolge erhalten, indem Sie die Datenbank aus der Liste im Portal auswählen und anschließend auf die Schaltfläche für die Verbindungszeichenfolgen klicken. Sie können außerdem die Verbindung über das Portal schnell testen, indem Sie auf die Schaltfläche für das testen der Verbindung für die ausgewählte Datenbank klicken. Für diesen Test müssen Sie die Option „Allow Microsoft Services to Connect to this Server“ (Microsoft Services die Verbindung mit diesem Server gestatten) auf der Registerkarte für die Firewallregeln im SQL Azure-Portal aktivieren.

Erstellen der Anwendung

Nach der Einrichtung des Kontos, der Erstellung des Servers, der Erstellung mindestens einer Datenbank und der Einrichtung einer Firewallregel, sodass eine Verbindung mit der Datenbank hergestellt werden kann, können Sie mit der Entwicklung der Anwendung mittels dieser Datenquelle beginnen.

Anders als im Fall von Windows Azure-Datenspeicherungsoptionen wie Tabellen, Warteschlangen oder Blobs müssen Sie bei der Verwendung von SQL Azure als Datenquelle für Ihr Projekt keine Komponenten in Ihrer Entwicklungsumgebung installieren. Bei Verwendung von Visual Studio 2010 können Sie einfach beginnen – Sie benötigen keine zusätzlichen SDKs, Tools oder sonstige Komponenten.

Obwohl sich zahlreiche Entwickler für die Verwendung eines Windows Azure-Front-Ends mit einem SQL Azure-Back-End entscheiden werden, ist diese Konfiguration nicht erforderlich. Sie können jeden Front-End-Client mit einer unterstützten Verbindungsbibliothek verwenden, wie ADO.NET oder ODBC. Dies kann beispielsweise auch eine Anwendung sein, die in Java oder PHP geschrieben wurde. Die Verbindung mit SQL Azure über OLE DB wird zurzeit nicht unterstützt.

Wenn Sie Visual Studio 2010 für die Entwicklung der Anwendung verwenden, können Sie die darin enthaltene Fähigkeit für die Anzeige oder Erstellung zahlreicher Objekte in der von Ihnen ausgewählten SQL Azure-Datenbankinstallation direkt vom Visual Studio Server Explorer aus nutzen. Dies sind Tabellen, Ansichten, gespeicherte Prozeduren Funktionen und Synonyme. Sie können außerdem mittels dieses Viewers die Daten anzeigen, die mit diesen Objekten verknüpft sind. Für viele Entwickler wird Visual Studio 2010 als primäres Tool für die Anzeige und Verwaltung von SQL Azure-Daten ausreichen. Das Fenster für die Server Explorer-Ansicht wird in Abbildung 2 dargestellt. Es werden sowohl eine lokale Datenbankinstallation als auch eine cloudbasierte Instanz gezeigt. Sie können sehen, dass sich die Strukturknoten in den beiden Ansichten etwas unterscheiden. Es gibt zum Beispiel keinen Assemblies-Knoten in der Cloudinstallation, da angepasste Assemblies in SQL Azure nicht unterstützt werden.

Abbildung 2 Anzeige von Datenverbindungen in Visual Studio Server Explorer

Wie bereits erwähnt, können Sie auch SQL Server Management Studio (SSMS) 2008 R2 in Verbindung mit SQL Azure verwenden. Mit SSMS 2008 R2 erhalten Sie Zugriff auf eine größere Anzahl von Prozessen für SQL Azure-Datenbanken als mit Visual Studio 2010. Ich verwende beide Tools, abhängig vom Prozess, den ich durchführen möchte. Ein Beispiel für einen Prozess, der in SSMS 2008 R2 (jedoch nicht in Visual Studio 2010) verfügbar ist, ist das Erstellen einer Datenbank mittels eines T-SQL-Skripts. Ein anderes Beispiel ist die Fähigkeit, Indexprozesse auf einfache Weise durchzuführen (erstellen, warten, löschen usw.). In Abbildung 3 wird ein Beispiel hierfür gezeigt.

Abbildung 3 Verwenden von SQL Server Management Studio 2008 R2 für die Verwaltung von SQL Azure

Neu in SQL Server 2008 R2 ist eine Datenebenenanwendung (DAC). DAC-Pacs sind Objekte, die SQL Server- oder SQL Azure-Datenbankschemen und -objekte zu einer einzelnen Entität verbinden. Sie können entweder Visual Studio 2010 (für die Erstellung) oder SQL Server 2008 R2 SSMS (für die Extrahierung) verwenden, um eine DAC von einer vorhandenen Datenbank aus zu erstellen.

Wenn Visual Studio 2010 mit einer DAC funktionieren soll, wählen Sie zunächst den Projekttyp für die SQL Server-Datenebenenanwendung in Visual Studio 2010 aus. Klicken Sie anschließend mit der rechten Maus auf den Namen des Projekts und dann auf die Option für den Import der Datenebenenanwendung. Es wird ein Assistent geöffnet, der Sie durch den Importvorgang führt. Wenn Sie SSMS verwenden, klicken Sie zunächst im Object Explorer auf die gewünschte Datenbank, dann auf „Aufgaben“ und anschließend auf „Datenebenenanwendung“, um die DAC zu erstellen.

Bei der generierten DAC handelt es sich um eine komprimierte Datei, die mehrere T-SQL- und XML-Dateien enthält. Sie können mit den Inhalten arbeiten, indem Sie mit der rechten Maustaste auf die .dacpac-Datei und anschließend auf „Entpacken“ klicken. SQL Azure unterstützt das Löschen, Bereitstellen, Extrahieren und Registrieren von DAC-Pacs, jedoch nicht deren Aktualisierung.

Ein anderes Tool, das Sie für die Verbindung mit SQL Azure verwenden können, ist die neueste Technologievorschau (Community Technology Preview, CTP)-Version des Tools mit dem Codenamen „Houston“. Houston ist ein auf Silverlight basierendes Verwaltungstool für SQL Azure-Installationen, das keinerlei Installationen erfordert. Bei der Verbindung mit einer SQL Azure-Installation mittels Houston müssen Sie den Standort des Rechenzentrums angeben (zum Zeitpunkt der Erstellung dieses Artikels sind dies North Central U.S. (nördliche Zentral-USA), South Central U.S. (südliche Zentral-USA), Nordeuropa, Zentraleuropa, Asien/Pazifik und Südostasien).

Houston befindet sich in der frühen Betaphase und die aktuelle Version (wie in Abbildung 44 gezeigt) ähnelt SSMS. Houston unterstützt die Arbeit mit Tabellen, Ansichten, Abfragen und gespeicherten Prozeduren in einer SQL Azure-Datenbankinstallation. Sie können auf Houston von der SQL Azure Labs-Site unter sqlazurelabs.com/houston.aspx aus zugreifen.

Abbildung 4 Verwendung von Houston für die Verwaltung von SQL Azure

Ein weiteres Tool, das Sie für die Verbindung mit einer SQL Azure-Datenbank verwenden können, ist SQLCMD (msdn.microsoft.com/library/ee336280). Trotz der Unterstützung von SQLCMD wird das OSQL-Befehlszeilentool nicht von SQL Azure unterstützt.

Verwenden von SQL Azure

Nun haben Sie eine Verbindung mit der SQL Azure-Installation hergestellt und eine neue, leere Datenbank erstellt. Was genau können Sie mit SQL Azure tun? Insbesondere möchten Sie wahrscheinlich wissen, was die Beschränkungen für die Erstellung von Objekten sind. Und wenn Sie diese Objekte erstellt haben, wie füllen Sie diese Objekte dann mit Daten?

Wie bereits zu Anfang erwähnt, stellt SQL Azure relationale Clouddatenspeicherung bereit, es gibt jedoch feine Unterschiede im Vergleich zu einer lokalen SQL Server-Installation. Beginnen wir mit der Objekterstellung, und betrachten wir einige der wesentlichen Unterschiede zwischen diesen beiden Tools.

Sie können mittels vertrauter Tools die am häufigsten verwenden Objekte in der SQL Azure-Datenbank erstellen. Die am häufigsten verwendeten relationalen Objekte (dazu zählen Tabellen, Ansichten, gespeicherte Prozeduren, Indizes und Funktionen) sind alle verfügbar. Es gibt jedoch eine Unterschiede hinsichtlich der Objekterstellung. Im Folgenden finden Sie eine Übersicht über diese Unterschiede:

• SQL Azure-Tabellen müssen einen geclusterten Index enthalten. Nicht geclusterte Indizes können anschließend in ausgewählten Tabellen erstellt werden. Sie können spatiale Indizes erstellen, jedoch keine XML-Indizes.
• Heaptabellen werden nicht unterstützt.
• Geospatiale CLR-Typen (wie Geography und Geometry) werden unterstützt, genauso wie der HierachyID-Datentyp. Andere CLR-Typen werden nicht unterstützt.
• Die Ansichterstellung muss die erste Anweisung in einem Batch sein. Die Erstellung einer Ansicht (oder gespeicherten Prozedur) mittels Verschlüsselung wird nicht unterstützt:
• Die Funktionen können skalar, inline oder Tabellenwertfunktionen mit mehreren Anweisungen sein, jedoch keine CLR-Funktionen.

Es gibt eine vollständige Referenz für teilweise unterstützte T-SQL-Anweisungen für SQL Azure auf MSDN unter msdn.microsoft.com/library/ee336267.

Denken Sie vor der Erstellung von Objekten daran, dass Sie eine Verbindung mit der Masterdatenbank herstellen, wenn Sie keine andere Datenbank in der Verbindungszeichenfolge angeben. Die USE (Datenbank)-Anweisung wird in SQL Azure für geänderte Datenbanken nicht unterstützt. Wenn Sie eine Verbindung mit einer anderen als der Masterdatenbank herstellen müssen, müssen Sie diese Datenbank ausdrücklich in der Verbindungszeichenfolge angeben, wie bereits erwähnt.

Migration und Laden von Daten

Wenn Sie SQL Azure-Objekte mittels einer vorhandenen lokal installierten Datenbank als Quelldaten und -strukturen erstellen möchten, können Sie einfach SSMS für das Skripten einer geeigneten DDL verwenden, um diese Objekte in SQL Azure zu erstellen. Verwenden Sie den Assistenten zum Generieren Skripts, und legen Sie die Option für das Skript für den Datenbankmodultyp als „SQL Azure“ fest.

Eine noch einfachere Methode für das Generieren eines Skripts ist die Verwendung des Migrations-Assistenten für SQL Azure, der zum Download von CodePlex unter sqlazuremw.codeplex.com verfügbar ist. Mit diesem praktischen Tool können Sie ein Skript generieren, um die Objekte zu erstellen, und können die Daten mittels bcp.exe als Massenupload laden.

Sie können auch ein SQL Server Integration Services (SSIS)-Paket entwerfen, um ein DDM- oder DDL-Skript zu extrahieren und auszuführen. Bei der Verwendung von SSIS werden Sie am häufigsten ein Paket entwerfen, das die DDL aus der Quelldatenbank extrahiert, für diese DDL ein SQL Azure-Skript erstellt und anschließend dieses Skript auf einer oder mehreren SQL Azure-Installationen ausführt. Sie können die verknüpften Daten auch als Teil des Ausführungspfads des Pakets laden. Weitere Informationen zur Arbeit mit SSIS finden Sie unter msdn.microsoft.com/library/ms141026.

Beachten Sie bezüglich der DDL-Erstellung und Datenmigration auch die CTP-Version des SQL Azure-Datensynchronisierungsdiensts (sqlazurelabs.com). Informationen zur Funktionsweise des Diensts erhalten Sie im Channel 9-Video mit dem Titel „Using SQL Azure Data Sync Service to provide Geo-Replication of SQL Azure Databases“ (Verwendung des SQL Azure-Datensynchronisierungsdiensts zur Bereitstellung von Geo-Replizierung von SQL Azure-Datenbanken) unter tinyurl.com/2we4d6q. Zurzeit wird der SQL Azure-Datensynchronisierungsdienst über Synchronization Groups (HUB- und MEMBER-Server) und anschließend eine geplante Synchronisierung auf der Ebene der einzelnen Tabellen in den für die Synchronisierung ausgewählten Tabellen ausgewählt.

Sie können das Microsoft Sync Framework Power Pack for SQL Azure für die Synchronisierung von Daten zwischen einer Datenquelle und einer SQL Azure-Installation verwenden. Zum Zeitpunkt der Erstellung dieses Artikels ist dieses Tool eine CTP-Version und unter tinyurl.com/2ecjwku verfügbar. Wenn Sie dieses Framework für die Durchführung aufeinander folgender oder laufender Datensynchronisierungen für die Anwendung verwenden, sollten Sie den verknüpften SDK herunterladen.

Was passiert, wenn die Größe der Quelldatenbank die maximal zulässige Größe für die SQL Azure-Datenbankinstallation überschreitet? Das würde bedeuten, dass sie den absoluten Höchstwert von 50 GB für die Business Edition oder, im Fall der anderen Programmoptionen, einen kleineren Wert überschreitet.

Zurzeit müssen Kunden die Daten manuell partitionieren (oder splitten), wenn die Datenbank die Programmgrenzen überschreitet. Microsoft hat angekündigt, dass es in der Zukunft eine SQL Azure-Funktion für die automatische Partitionierung bereitstellen wird. Beachten Sie, dass die T-SQL-Tabellenpartitionierung nicht in SQL Azure unterstützt wird. Es gibt ein kostenloses Dienstprogramm mit dem Namen Enzo SQL Shard (enzosqlshard.codeplex.com), das Sie für die Partitionierung der Datenquelle verwenden können.

Es gibt weitere Unterschiede zwischen SQL Server und SQL Azure hinsichtlich des Ladens von Daten und des Zugriffs auf Daten, Die Sie kennen sollten.

Vor kurzem wurde die Fähigkeit hinzugefügt, eine SQL Azure-Datenbank mittels des Datenbank-Kopierbefehls zu kopieren. Die Syntax eines Kopiervorgangs zwischen Servern sieht folgendermaßen aus:

    CREATE DATABASE DB2A AS COPY OF Server1.DB1A

Die T-SQL INSERT-Anweisung wird unterstützt (ausgenommen die Aktualisierung mit Ansichten oder die Bereitstellung eines Sperrhinweises innerhalb einer INSERT-Anweisung).

In Bezug auf die Datenmigration gibt es für T-SQL DROP DATABASE und andere DDL-Befehle zusätzliche Beschränkungen, wenn sie für eine SQL Azure-Installation ausgeführt werden. Außerdem werden die Befehle T-SQL RESTORE und ATTACH DATABASE nicht unterstützt. Und schließlich wird die T-SQL-Anweisung EXECUTE AS (Anmeldung) nicht unterstützt.

Zugriff auf die Daten und Programmierbarkeit

Betrachten wir nun einige häufige Programmierprobleme, die bei der Arbeit mit Clouddaten auftreten. Zunächst sollten Sie überlegen, wo Sie die Entwicklungsumgebung einrichten. Wenn Sie MSDN-Abonnement sind und mit einer Datenbank arbeiten können, die kleiner als 1 GB ist, kann es durchaus sinnvoll sein, die Entwicklung mittels einer Cloudinstallation durchzuführen (Testdatenbank). Auf diese Weise gibt es keine Probleme bei der Migration von einer lokalen zu einer Clouddatenbank. Wenn Sie ein reguläres SQL Azure-Konto verwenden (also kein MSDN-Abonnent sind), können Sie direkt auf der Basis der Cloudinstanz entwickeln. Dies wird wahrscheinlich eine Cloudkopie der Produktionsdatenbank sein. Die Entwicklung direkt in der Cloud ist in keinem Szenario zu empfehlen.

Wenn Sie mit einer lokalen Installation der SQL Server-Datenbank als Datenquelle für Ihre Entwicklung arbeiten, müssen Sie einen Mechanismus für die Synchronisierung der lokalen mit der Cloudinstallation entwickeln. Dies kann mittels einer der bereits erwähnten Methoden erfolgen, und Tools wie Data Sync Services und Sync Framework werden unter Berücksichtigung dieses Szenarios entwickelt.

Solange wie Sie nur die unterstützten Funktionen verwenden, ist das Verfahren für den Wechsel der Anwendung von einer lokal installierten SQL Server-Installation zu einer SQL Azure-Datenbank einfach – Sie müssen nur die Verbindungszeichenfolge in der Anwendung ändern.

Unabhängig davon, ob Sie die Entwicklungsinstallation lokal oder in der Cloud einrichten, müssen Sie einige Unterschiede hinsichtlich der Programmierbarkeit zwischen SQL Server und SQL Azure kennen. Ich habe die Unterschiede zwischen SQL Azure und T-SQL und die Verbindungszeichenfolgen bereits behandelt. Außerdem müssen alle Tabellen mindestens über einen geclusterten Index verfügen (Heaptabellen werden nicht unterstützt).

Wie bereits erwähnt, wird die USE-Anweisung für geänderte Datenbanken nicht unterstützt. Das bedeutet auch, dass es keine Unterstützung für verteilte (datenbankübergreifende) Transaktionen oder Abfragen gibt. Verlinkte Server werden nicht unterstützt.

Andere Optionen, die bei der Arbeit mit einer SQL Azure-Datenbank nicht verfügbar sind, sind:

• Volltextindexierung
• Angepasste CLR-Typen (die CLR-Typen Geography und Geometry werden jedoch unterstützt)
• RowGUIDs (verwenden Sie stattdessen den uniqueidentifier-Typ mit der NEWID-Funktion)
• XML-Spaltenindizes
• FILESTREAM-Datentyp
• Spalten mit geringer Dichte

Für die Datenbank wird stets die standardmäßige Sortierung verwendet. Legen Sie die Spaltensortierung mittels der T-SQL COLLATE-Anweisung auf den gewünschten Wert fest, wenn Sie die Sortierung anpassen möchten.

Sie können zurzeit den SQL Profiler oder den Assistenten für die Datenbankanpassung nicht für SQL Azure-Datenbanken verwenden.

Einige wichtige Tools, die Sie zusammen mit SQL Azure für die Anpassung und Überwachung verwenden können, sind:

• SSMS Query Optimizer zur Anzeige der geschätzten oder tatsächlichen Details des Abfrageausführungsplans und der Clientstatistiken
• Select Dynamic Management-Ansichten zur Überwachung des Status
• Entity Framework zur Verbindung mit SQL Azure nach der Erstellung der anfänglichen Modell- und Zuordnungsdateien, indem eine Verbindung mit einer lokalen Kopie der SQL Azure-Datenbank hergestellt wurde.

Abhängig von der Art der von Ihnen entwickelten Anwendung können Sie SSAS, SSRS, SSIS oder PowerPivot verwenden. Sie können diese Produkte auch als Consumer von SQL Azure-Datenbankdaten verwenden. Stellen Sie einfach eine Verbindung mit dem SQL Azure-Server und der ausgewählten Datenbank her, indem Sie die bereits beschriebenen Methoden verwenden.

Sie sollten auch das Verhalten von Transaktionen in SQL Azure vollständig verstehen. Wie bereits erwähnt, werden nur lokale Transaktionen (innerhalb derselben Datenbank) unterstützt. Außerdem ist READ COMMITTED SNAPSHOT die einzige Transaktions-Isolierungsstufe, die für eine auf SQL Azure gehostete Datenbank verfügbar ist. Mittels dieser Isolierungsstufe können Leser die letzte konsistente Datenversion abrufen, die beim START der Anweisung verfügbar war.

SQL Azure erkennt Updatekonflikte nicht. Dies wird auch als optimistisches Gleichzeitigkeitsmodell bezeichnet, da es verloren gegangene Updates, nicht wiederholbare Lesevorgänge und Phantome geben kann. Es können auch ungültige Lesevorgänge (Dirty Reads) auftreten.

Datenbankadministration

Im Allgemeinen besteht die Administratorrolle bei der Verwendung von SQL Azure in der logischen Installationsverwaltung. Die physische Verwaltung wird von der Plattform übernommen. In der Praxis bedeutet dies, dass es keine physischen Server gibt, die gekauft, installiert, gepatcht, gewartet oder geschützt werden müssen. Dateien, Protokolle, tempdb usw. können nicht an bestimmten physischen Speicherorten gespeichert werden. Daher werden die T-SQL-Befehle USE <Datenbank>, FILEGROUP, BACKUP, RESTORE oder SNAPSHOT nicht unterstützt.

Der SQL Agent wird in SQL Azure nicht unterstützt. Es müssen außerdem keine Replizierungen, Protokollsendungen, Datenbankspiegelungen und auch kein Clustering konfiguriert werden. Wenn Sie eine lokale, synchronisierte Kopie von SQL Azure-Schemen und -Daten pflegen müssen, können Sie eines der bereits behandelten Tools für die Datenmigration und -synchronisierung verwenden. Diese funktionieren in beiden Richtungen. Sie können auch den DATABASE COPY-Befehl verwenden.

Welche anderen Aufgaben außer der Datensynchronisierung müssen Administratoren außerdem im Zusammenhang mit einer SQL Azure-Installation durchführen? 

Am häufigsten werden dies Aufgaben im Bereich der logischen Administration sein. Dazu gehören Aufgaben in den Bereichen Sicherheit und Leistungsverwaltung. Außerdem müssen möglicherweise die Kapazitätsauslastung und die entsprechenden Kosten überwacht werden. Um Sie bei diesen Aufgaben zu unterstützen, stellt SQL Azure ein öffentliches Dashboard für die Anzeige des Statusverlaufs bereit, auf dem der aktuelle Status des Diensts und Daten zum aktuellen Verlauf angezeigt werden (ein Beispiel für die Verlaufsanzeige sehen Sie in Abbildung 5), siehe microsoft.com/windowsazure/support/status/servicedashboard.aspx.

Abbildung 5 SQL Azure-Statusverlauf

SQL Azure stellt standardmäßig eine hohe Sicherheit bereit. Es erzwingt für alle (über Firewallregeln) zugelassenen Clientverbindungen die SSL-Verschlüsselung. Anmeldungen am Server sowie Benutzer und Rollen auf Datenbankebene werden ebenfalls geschützt. Es gibt keine Rollen auf Serverebene in SQL Azure. Die Verschlüsselung von Verbindungszeichenfolgen stellt ein bewährtes Verfahren dar. Außerdem sollten Sie Windows Azure-Zertifikate für zusätzliche Sicherheit verwenden. Weitere Details finden Sie unter blogs.msdn.com/b/sqlazure/archive/2010/09/07/10058942.aspx.

Im Bereich der Leistung stellt SQL Azure Funktionen wie den Abbruch lang andauernder Transaktionen und von Leerlaufverbindungen (Verbindungen, die mehr als 30 Minuten inaktiv sind) bereit. Obwohl Sie weder SQL Profiler noch Nachverfolgungsflags zur Optimierung der Leistung verwenden können, können Sie SQL Query Optimizer zur Anzeige von Abfrageausführungsplänen und Clientstatistiken verwenden. Sie können außerdem mittels der standardmäßigen T-SQL-Methoden Statistikverwaltung und Indexoptimierung durchführen.

Es sind auch einige dynamische Verwaltungsansichten (für die Datenbank, die Ausführung oder Transaktionsinformationen) für die Datenbankadministration verfügbar. Dies sind include sys.dm_exec_connections, _requests, _sessions, _tran_database_transactions, _active_transactions und _partition_stats. Eine vollständige Liste der unterstützten dynamischen Verwaltungsansichten für SQL Azure finden Sie unter msdn.microsoft.com/library/ee336238.aspx#dmv.

Es sind auch einige neue Ansichten wie sys.database_usage und sys.bandwidth_usage verfügbar. Diese zeigen die Anzahl, den Typ und die Größe der Datenbanken sowie die Bandbreitennutzung der einzelnen Datenbanken an, sodass Administratoren die SQL Azure-Abrechnungen verstehen können. In Abbildung 6 sehen Sie ein Beispiel hierfür. In dieser Ansicht wird die Größe in KB angegeben. Sie können mittels des folgenden Befehls den beanspruchten Speicherplatz überwachen:

    SELECT SUM(reserved_page_count) * 8192 
    FROM sys.dm_db_partition_stats

Abbildung 6 Bandbreitennutzung in SQL Query

Sie können auf die aktuellen Abrechnungen für die SQL Azure-Installation auch über das SQL Azure-Portal zugreifen, indem Sie auf den Link für die Abrechnung oben rechts auf dem Bildschirm klicken.

Weitere Informationen

Weitere Informationen zu SQL Azure finden Sie im Windows Azure-Schulungskit. Dieser enthält praktische Schulungen zu SQL Azure, Whitepapers, Videos und mehr. Der Schulungskit ist unter microsoft.com/downloads/details.aspx?FamilyID=413E88F8-5966-4A83-B309-53B7B77EDF78 verfügbar.

Sie sollten auch den SQL Azure-Teamblog unter blogs.msdn.com/b/sqlazure/ lesen und sich im MSDN SQL Azure Developer Center unter msdn.microsoft.com/windowsazure/sqlazure informieren.

Wenn Sie weiterhin vorab über neue Funktionen für SQL Azure informiert werden möchten, sollten Sie SQL Azure Labs unter sqlazurelabs.com besuchen.                                                                                

Lynn Langitist Entwickler-Evangelist für Microsoft in Südkalifornien. Sie hat zwei Bücher zu SQL Server Business Intelligence veröffentlicht und eine Reihe von Schulungsunterlagen erstellt, um Kindern das Programmieren zu erklären, die Sie unter TeachingKidsProgramming.org finden können. Lesen Sie ihren Blog unter blogs.msdn.com/b/SoCalDevGal.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: George Huey und David Robinson