Prise en main du développement SQL Azure

  • Article

Article original sur https://msdn.microsoft.com/fr-fr/magazine/gg309175.aspx. Auteur: Lynn Langit

Microsoft Windows Azure offre plusieurs possibilités pour le stockage des données : le stockage Windows Azure et SQL Azure. Vous pouvez utiliser l’une de ces méthodes ou les deux dans votre projet. Le stockage Windows Azure contient habituellement trois types de structures de stockage : les tables, les files d’attente et les objets BLOB.

SQL Azure est un service de stockage de données relationnelles en nuage. Cette offre présente des avantages, notamment la possibilité d’utiliser un modèle de développement relationnel familier qui intègre des outils et des utilitaires, mais aussi la majeure partie du langage SQL Server standard (T-SQL). Il va sans dire que les développeurs travaillant dans le nuage avec des structures relationnelles bien comprises, par exemple des tables, des vues et des procédures stockées, voient leur productivité renforcée sur cette nouvelle plateforme. Ils bénéficient également d’autres avantages, comme un besoin limité en tâches d’administration physiques de la base de données pour assurer la configuration, la maintenance et la sécurité des serveurs, ainsi qu’une prise en charge intégrée pour plus de fiabilité, de disponibilité et d’évolutivité.

Je ne compte pas aborder dans cet article le stockage Windows Azure ni établir de comparaison entre ces deux modes de stockage. Pour en savoir plus à propos de ces options de stockage, je vous invite à lire la colonne des Points sur les données de Julie Lerman datée du mois de juillet 2010 (msdn.microsoft.com/magazine/ff796231). Il est important de remarquer que les tables Windows Azure ne sont pas des tables relationnelles. L’intérêt ici est de comprendre les capacités offertes par SQL Azure.

Cet article expliquera les différences entre SQL Server et SQL Azure. Vous devez comprendre en détail chacune de ces différences pour pouvoir utiliser au mieux vos connaissances actuelles en SQL Server lorsque vous travaillez sur des projets qui utilisent SQL Azure comme source de données.

Si vous êtes novice dans l’utilisation de l’informatique en nuage, il vous sera peut-être utile de lire quelques documents sur Windows Azure avant de poursuivre cet article. Pour commencer, je vous conseille de consulter le centre de développement cloud MSDN à l’adresse suivante https://msdn.microsoft.com/ff380142.

Prise en main de SQL Azure

Pour commencer à travailler avec SQL Azure, vous devez configurer un compte. Si vous êtes abonné MSDN, vous pouvez vous servir de trois bases de données SQL Azure (de 1 Go chacune au maximum) pendant une durée maximale de 16 mois (vous trouverez des détails complémentaires sur le site msdn.microsoft.com/subscriptions/ee461076) en tant que sandbox du développeur. Pour vous abonner à un compte SQL Azure standard (des frais de stockage et de transfert de données peuvent s’appliquer), rendez-vous sur le site https://www.microsoft.com/france/windows-azure/Offres.aspx.

Après vous être abonné à un compte SQL Azure, le moyen le plus simple pour y accéder est de vous rendre sur le portail Web à l’adresse sql.azure.com. Vous devez vous connecter au moyen de l’identifiant Windows Live ID associé à votre compte Windows Azure. Une fois la connexion établie, vous pouvez créer votre installation serveur et commencer à développer votre application.

La Figure 1 présente un exemple du portail de gestion Web de SQL Azure. C’est sur cette page que sont répertoriés les serveurs et les bases de données associées. Notez également la présence, sur ce portail Web, d’un onglet destiné à la gestion des paramètres du pare-feu pour votre installation SQL Azure en particulier.

 

Figure 1 Récapitulatif d’une base de données SQL Azure

À la création d’une installation serveur SQL Azure, une chaîne aléatoire est affectée au nom du serveur. En règle générale, au moment de créer le serveur, vous devez également définir le nom d’utilisateur de l’administrateur, le mot de passe, l’emplacement géographique du serveur et les règles de pare-feu. Vous pouvez sélectionner l’emplacement de votre installation SQL Azure au moment de créer le serveur. Une liste d’emplacements (centres de données) vous est présentée parmi lesquels choisir. Si la partie frontale de votre application est intégrée à Windows Azure, vous pouvez placer cette installation et votre installation SQL Azure sur le même emplacement géographique en les associant.

Par défaut, vous ne disposez d’aucun accès à votre serveur. Vous devez donc créer les règles de pare-feu de tous les IP client. SQL Azure utilise le port 1433. Assurez-vous que ce port est également ouvert pour votre application cliente. Pour vous connecter à SQL Azure, vous utilisez un nom d’utilisateur au format nomutilisateur@nomserveur. SQL Azure prend en charge l’authentification SQL Server uniquement et non l’authentification Windows. Les connexions MARS (Multiple Active Result Set) sont prises en charge.

Un arrêt des connexions ouvertes intervient après 30 minutes sans activité. De même, la connexion est abandonnée en cas de requêtes et de transactions de longue durée ou lorsque les ressources sont utilisées de manière excessive. Dans le cadre des meilleures pratiques de développement concernant vos applications, mieux vaut ouvrir, utiliser puis fermer manuellement ces connexions pour intégrer une logique de rétablissement de la connexion pour les connexions abandonnées ou pour éviter la mise en cache des connexions du fait de ces comportements. Pour en savoir plus sur les protocoles client pris en charge pour SQL Azure, nous vous invitons à lire l’article du blog de Steve Hale à l’adresse blogs.msdn.com/b/sqlnativeclient/archive/2010/02/12/using-sql-server-client-apis-with-sql-azure-vversion-1-0.aspx.

Une autre meilleure pratique consiste à chiffrer votre chaîne de connexion pour empêcher les attaques de l’intercepteur.

Si vous n’indiquez aucun nom de base de données dans la chaîne de connexion, vous êtes connecté à la base de données master par défaut. Dans SQL Azure, l’instruction T-SQL USE n’est pas prise en charge pour changer de base de données. Vous devez indiquer dans la chaîne de connexion la base de données à laquelle vous souhaitez vous connecter (en partant du principe que vous voulez vous connecter à une base de données autre que la base master). Voici un exemple de connexion ADO.NET :

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

Configuration des bases de données

Après vous être connecté avec succès à votre installation, vous pouvez créer une ou plusieurs bases de données. Bien que vous puissiez créer des bases de données à l’aide du portail SQL Azure, vous allez utiliser d’autres outils, comme SQL Server Management Studio 2008 R2. Par défaut, vous pouvez créer jusqu’à 149 bases de données pour chaque installation serveur SQL Azure. Si vous avez besoin de davantage de bases de données, appelez le bureau Windows Azure et demander à ce que cette limite soit relevée.

Au moment de créer une base de données, vous devez sélectionner sa taille maximale. Les options utilisées pour le calcul de la taille (et la facturation) sont Web ou Business Edition. Web Edition est la version par défaut. Elle prend en charge des bases de données de 1 ou 5 Go au total. Business Edition prend en charge des bases de données pouvant atteindre 50 Go, par incrément de 10 Go, soit 10 Go, 20 Go, 30 Go, 40 Go et 50 Go.

Pour définir la taille limite de votre base de données au moment de sa création, vous utilisez le mot clé MAXSIZE. Pour modifier cette limite de taille ou l’édition (Web ou Business) après la création initiale, utilisez l’instruction ALTER DATABASE. Si la taille ou la limite de capacité de l’édition choisie est atteinte, le code d’erreur 40544 s’affiche. La mesure de la taille de la base de données n’inclut pas la base de données master ni les journaux de base de données. Pour en savoir plus sur la taille et la tarification, consultez le site https://www.microsoft.com/france/windows-azure/Offres.aspx.

Il est important de vous rendre compte que lorsque vous créez une base de données SQL Azure, vous créez en réalité trois réplicas de cette base. Il s’agit en effet de garantir une disponibilité élevée. Tout cela est entièrement transparent pour vous. La nouvelle base de données vous semble unique.

Pour obtenir rapidement les informations de la chaîne de connexion après avoir créé une base de données, vous pouvez sélectionner cette base de données dans la liste fournie sur le portail, puis cliquer sur le bouton Connection Strings. Vous pouvez également rapidement tester la connectivité via le portail en cliquant sur le bouton Test Connectivity pour la base de données sélectionnée. Pour la réussite de ce test, vous devez activer l’option Allow Microsoft Services to Connect to this Server dans l’onglet Firewall Rules du portail SQL Azure.

Création de votre application

Après avoir configuré votre compte, créé votre serveur, créé au moins une base de données et défini une règle de pare-feu pour pouvoir vous connecter à la base de données, vous pouvez commencer à développer votre application à l’aide de cette source de données.

Contrairement aux options de stockage de données de Windows Azure, notamment les tables, les files d’attente ou les objets BLOB, vous ne devez rien installer dans votre environnement de développement si vous utilisez SQL Azure comme source de données pour votre projet. Si vous utilisez Visual Studio 2010, vous êtes opérationnel sur le champ. Vous n’avez pas besoin de kit de développement logiciel (SDK) ni d’outils supplémentaires.

Même si la plupart des développeurs préfèrent utiliser une partie frontale Windows Azure avec un système principal SQL Azure, je ne recommande pas cette configuration. Libre à vous d’utiliser n’importe quel client frontal avec une bibliothèque de connexions prise en charge telles que ADO.NET ou ODBC. Cela pourrait être, par exemple, une application écrite en Java ou PHP. La connexion à SQL Azure via OLE DB n’est actuellement pas prise en charge.

Si vous utilisez Visual Studio 2010 pour développer votre application, profitez des fonctionnalités qui vous sont offertes pour afficher ou créer de nombreux types d’objets dans votre installation de base de données SQL Azure, directement depuis l’Explorateur de serveurs de Visual Studio. Ces objets sont des tables, des vues, des procédures stockées, des fonctions et des synonymes. Vous pouvez également utiliser cette visionneuse pour afficher les données associées à ces objets. La plupart des développeurs se contentent d’utiliser Visual Studio 2010 comme outil principal pour voir et gérer les données SQL Azure. La fenêtre Explorateur de serveurs vous est présentée dans la Figure 2. Y figurent à la fois une installation en local d’une base de données et une instance dans le nuage. Vous constatez que les nœuds de l’arborescence diffèrent légèrement dans ces deux vues. Par exemple, l’installation dans le nuage ne comporte aucun nœud Assemblys car les assemblages personnalisés ne sont pas pris en charge dans SQL Azure.

Figure 2 Affichage des connexions de données dans l’Explorateur de serveurs Visual Studio

Tout comme je l’ai mentionné précédemment, il vous sera peut-être utile de travailler avec SQL Azure et un autre outil du type SQL Server Management Studio (SSMS) 2008 R2. Avec SSMS 2008 R2, vous accédez à un jeu d’opérations plus complet pour les bases de données SQL Azure que dans Visual Studio 2010. J’utilise ces deux outils en fonction de l’opération que j’essaye d’exécuter. Par exemple, dans SSMS 2008 R2 (contrairement à Visual Studio 2010), il est possible de créer une nouvelle base de données à l’aide d’un script T-SQL. Autre exemple : SSMS 2008 R2 permet d’exécuter facilement des opérations d’indexation (création, maintenance, suppression, etc.). Un exemple vous est proposé Figure 3.

Figure 3 Utilisation de SQL Server Management Studio 2008 R2 pour gérer SQL Azure

Une application de la couche Données ou DAC est désormais utilisée dans SQL Server 2008 R2. Les packages DAC sont des objets qui combinent, dans une seule et même entité, des schémas et des objets de base de données SQL Server ou SQL Azure. Vous pouvez utiliser aussi bien Visual Studio 2010 (pour créer) ou SQL Server 2008 R2 SSMS (pour extraire) pour créer une DAC depuis une base de données existante.

Si vous préférez utiliser Visual Studio 2010 pour travailler avec une DAC, il vous faut commencer par sélectionner le type de projet d’application de couche Données de SQL Server dans Visual Studio 2010. Puis, dans l’Explorateur de solutions, vous devez cliquer sur le nom de votre projet avec le bouton droit de la souris et sélectionner Importer l’application de la couche Données. Un Assistant s’ouvre pour vous guider tout au long du processus d’importation. Si vous utilisez SSMS, commencez par cliquer à l’aide du bouton droit de la souris sur la base de données que vous souhaitez utiliser dans l’Explorateur d’objets, cliquez sur Tâches, puis sur Extraire l’application de la couche Données pour créer la DAC.

La DAC générée est un fichier compressé qui contient plusieurs fichiers T-SQL et XML. Pour travailler avec ce contenu, cliquez sur fichier .dacpac à l’aide du bouton droit de la souris et sélectionnez Décompresser. SQL Azure prend en charge la suppression, le déploiement, l’extraction et l’enregistrement des packages DAC mais ne prend par contre pas en charge leur mise à niveau.

Il existe un autre outil que vous pouvez utiliser pour vous connecter à SQL Azure. Il s’agit de toute dernière version préliminaire CTP (Community Technology Preview) d’un outil qui répond au nom de code « Houston ». Houston est un outil de gestion Silverlight sans installation pour les installations SQL Azure. Lorsque vous vous connectez à une installation SQL Azure à l’aide de Houston, vous indiquez l’emplacement du centre de données (au moment de rédiger cet article, vous avez le choix entre États-Unis centre nord, États-Unis centre sud, Europe du nord, Europe centrale, Asie-Pacifique ou Asie du sud-est).

Houston est actuellement en version bêta et sa version actuelle (présentée dans la Figure 4) ressemble quelque peu à SSMS. Houston permet de travailler avec des tables, des vues, des requêtes et des procédures stockées dans une installation de base de données SQL Azure. Vous pouvez accéder à Houston depuis le site SQL Azure Labs à l’adresse sqlazurelabs.com/houston.aspx.

 

Figure 4 Utilisation de Houston pour gérer SQL Azure

Il vous est également possible d’utiliser SQLCMD (msdn.microsoft.com/library/ee336280) pour vous connecter à une base de données SQL Azure. Même si SQLCMD est un outil pris en charge, l’outil de ligne de commande OSQL, quant à lui, ne l’est pas par SQL Azure.

Utilisation de SQL Azure

À présent, vous êtes connecté à votre installation SQL Azure et vous avez créé une base de données vide. Que pouvez-vous faire exactement avec SQL Azure ? Vous devez tout particulièrement vous demander quelles sont les limites fixées à la création d’objets. De plus, après la création de ces objets, comment les alimentez-vous en données ?

Tout comme je l’ai mentionné au début de cet article, SQL Azure propose un stockage des données relationnelles en nuage mais possède néanmoins quelques différences subtiles au niveau de ses fonctionnalités par rapport à une installation SQL Server sur site. Commençons par la création d’objets et observons les principales différences.

Vous pouvez créer la plupart des objets les plus utilisés dans votre base de données SQL Azure à l’aide des méthodes habituelles. Les objets relationnels les plus couramment utilisés (notamment les tables, les vues, les procédures stockées, les index et les fonctions) sont tous disponibles. Il existe cependant quelques différences concernant la création des objets. En voici un récapitulatif :

  • Les tables SQL Azure doivent contenir un index en cluster. Il est possible de créer par la suite les index non en cluster dans les tables sélectionnées. Vous pouvez créer des index spatiaux mais aucun index XML.
  • Les tables HEAP ne sont pas prises en charge.
  • Les types géospatiaux CLR (Geography et Geometry) sont pris en charge, tout comme l’est le type de données HierachyID. Les autres types CLR ne sont pas pris en charge.
  • La création de la vue doit correspondre à la première instruction d’un lot. De même, la création de la vue (ou de la procédure stockée) au moyen du chiffrement n’est pas prise en charge.
  • Les fonctions peuvent être scalaires, en ligne ou tabulaires à plusieurs instructions mais en aucun cas de type CLR.

Pour bénéficier d’une référence complète sur les instructions T-SQL partiellement prises en charge pour SQL Azure, consultez MSDN à l’adresse msdn.microsoft.com/library/ee336267

Avant de commencer à créer des objets, n’oubliez pas que vous êtes connecté à la base de données master si vous n’avez pas indiqué de base de données différente dans votre chaîne de connexion. Dans SQL Azure, l’instruction USE (base de données) n’est pas prise en charge pour changer de base de données. Aussi, si vous devez vous connecter à une base de données autre que la base de données master, vous devez mentionner cette base de données de manière explicite dans votre chaîne de connexion, tel que cela vous a été expliqué précédemment.

Migration et chargement des données

Si vous prévoyez de créer des objets SQL Azure en utilisant comme données et structures source une base de données sur site existante, il vous suffit d’utiliser SSMS pour rédiger le script d’un DDL qui créera ces objets sur SQL Azure. Utilisez l’Assistant Générer des scripts et définissez l’option Générer un script pour le type de moteur de base de données sur SQL Azure.

Il existe une manière encore plus simple de générer un script. Pour cela, utilisez l’Assistant SQL Azure Migration proposé en téléchargement sur le site de CodePlex à l’adresse sqlazuremw.codeplex.com. Grâce à cet outil tout particulièrement utile, vous pouvez générer un script pour créer les objets, ainsi que charger les données via une copie en bloc au moyen de bcp.exe.

Vous pouvez également concevoir un package SQL Server Integration Services (SSIS) pour extraire et exécuter un script DDM ou DDL. Si vous utilisez SSIS, vous privilégiez la conception d’un package qui extrait le DDL de la base de données source, qui rédige le script du DDL pour SQL Azure et qui exécute ce script sur une ou plusieurs installations SQL Azure. Vous pouvez également choisir de charger les données associées dans le cadre du chemin d’exécution de ce package. Pour en savoir plus sur l’utilisation de SSIS, lisez l’article msdn.microsoft.com/library/ms141026.

La version CTP de SQL Azure Data Sync Services (sqlazurelabs.com) peut également se révéler utile concernant la création du DDL et la migration des données. Pour voir ce service à l’œuvre, visionnez la vidéo « Using SQL Azure Data Sync Service to provide Geo-Replication of SQL Azure Databases » sur l’utilisation du service de synchronisation des données SQL Azure pour proposer une géoréplication des bases de données SQL Azure. Rendez-vous pour cela sur le site de Channel 9 à l’adresse tinyurl.com/2we4d6q. Habituellement, le service de synchronisation des données SQL Azure fonctionne via des groupes de synchronisation (serveurs HUB et MEMBER) puis via une synchronisation planifiée au niveau des tables individuelles dans les bases de données sélectionnées pour synchronisation.

Vous pouvez utiliser le Microsoft Sync Framework Power Pack pour SQL Azure afin de synchroniser les données entre une source de données et une installation SQL Azure. Au moment de rédiger cet article, cet outil est proposé en version CTP et accessible sur le site tinyurl.com/2ecjwku. Si vous utilisez ce cadre pour effectuer la synchronisation en cours ou à venir des données de votre application, il vous faudra peut-être également télécharger le kit de développement logiciel correspondant.

Que faire à présent si la taille de votre base de données source dépasse la taille maximale autorisée pour une installation de base de données SQL Azure ? Il s’agit ici d’une taille supérieure à la taille maximale absolue de 50 Go pour la Business Edition ou d’une limite plus faible en fonction des autres options du programme.

Actuellement, les clients doivent partitionner (ou éclater) leurs données manuellement si la taille de leur base de données dépasse la limite définie par le programme. Microsoft a annoncé la sortie future d’un utilitaire de partitionnement automatique pour SQL Azure. En attendant, il est important de noter que le partitionnement de table T-SQL n’est pas pris en charge dans SQL Azure. Il existe un utilitaire gratuit appelé Enzo SQL Shard (enzosqlshard.codeplex.com) servant au partitionnement de votre source de données.

SQL Server et SQL Azure présentent d’autres différences intéressantes, notamment concernant le chargement des données et l’accès aux données.

Depuis peu, il est possible de copier une base de données SQL Azure via la commande de copie de la base de données. La syntaxe pour la copie entre serveurs est la suivante :

 CREATE DATABASE DB2A AS COPY OF Server1.DB1A

L’instruction T-SQL INSERT est prise en charge (à l’exception de la mise à jour avec les vues ou de l’insertion d’une information de verrouillage dans une instruction INSERT).

Davantage liées à la migration des données, l’instruction T-SQL DROP DATABASE et les autres commandes DDL possèdent des limites lorsqu’elles sont exécutées dans une installation SQL Azure. De plus, les commandes T-SQL RESTORE et ATTACH DATABASE ne sont pas prises en charge. Enfin, l’instruction T-SQL EXECUTE AS (connexion) n’est pas prise en charge.

Accès aux données et programmabilité

À présent, regardons de plus près les problèmes de programmation les plus courants avec les données en nuage. Tout d’abord, vous devez savoir où configurer votre environnement de développement. Si vous êtes abonné MSDN et que vous pouvez travailler avec une base de données de moins d’1 Go, mieux vaut penser développer une installation en nuage uniquement (bac à sable ou sandbox). De la sorte, vous ne rencontrerez aucun problème lorsqu’il s’agira de migrer votre installation en local vers une installation en nuage. Au moyen d’un compte SQL Azure classique (aucun abonnement MSDN), vous pouvez développer directement votre application sur l’instance en nuage (vraisemblablement en utilisant une copie dans le nuage de votre base de données de production). Bien entendu, ce type de développement, directement à partir du nuage, n’est pas pratique dans tous les cas.

Si vous choisissez de travailler avec une base de données SQL Server sur site comme source de données de développement, vous devez développer un mécanisme de synchronisation de votre installation locale avec l’installation dans le nuage. Pour ce faire, vous pouvez utiliser l’une des méthodes abordées précédemment. Des outils tels que Data Sync Services et Sync Framework ont été conçus à cet effet.

Tant que vous n’utilisez que les fonctionnalités prises en charge, la méthode permettant de faire basculer votre application d’une installation SQL Server sur site à une base de données SQL Azure est simple. Il vous suffit de modifier la chaîne de connexion de votre application.

Que vous configuriez votre installation de développement en local ou dans le nuage, vous devez néanmoins comprendre les différences de programmation entre SQL Server et SQL Azure. J’ai déjà abordé les différences concernant les instructions T-SQL et la chaîne de connexion. De plus, toutes les tables doivent utiliser un index en cluster au minimum (les tables HEAP ne sont pas prises en charge).

Tel que mentionné précédemment, l’instruction USE pour changer les bases de données n’est pas prise en charge. Cela signifie également que les transactions ou les requêtes distribuées (entre bases de données) ne sont pas prises en charge, tous comme les serveurs liés.

Lorsque vous travaillez avec une base de données SQL Azure, il existe d’autres options qui ne sont pas disponibles :

  • Indexation de texte intégral
  • Types personnalisés CLR (toutefois, les types CLR Geometry et Geography sont pris en charge)
  • RowGUID (utilisez plutôt le type uniqueidentifier avec la fonction NEWID)
  • Index de colonne XML
  • Type de données Filestream
  • Colonnes fragmentées

L’assemblage par défaut est toujours utilisé pour la base de données. Pour modifier l’assemblage, définissez l’assemblage au niveau des colonnes sur la valeur souhaitée à l’aide de l’instruction T-SQL COLLATE.

Enfin, vous ne pouvez actuellement pas utiliser SQL Profiler ou l’Assistant Paramétrage de base de données sur votre base de données SQL Azure.

Voici certains outils importants qu’il est possible d’utiliser avec SQL Azure pour le paramétrage et la surveillance :

  • Optimiseur de requête SSMS : pour afficher les détails du plan d’exécution prévu ou réel des requêtes et les statistiques du client
  • Sélection des vues de gestion dynamique : pour surveiller la santé et l’état
  • Entity Framework : pour vous connecter à SQL Azure après que le modèle initial et les fichiers de mappage ont été créés par connexion à une copie en local de votre base de données SQL Azure

En fonction du type d’application que vous développez, vous pouvez utiliser SSAS, SSRS, SSIS ou PowerPivot. Vous pouvez aussi vous servir de l’un de ces produits en tant qu’utilisateurs des données de la base de données SQL Azure. Pour cela, il vous suffit de vous connecter à votre serveur SQL Azure et à la base de données sélectionnée au moyen des méthodes déjà décrites dans cet article.

Il est également important de bien comprendre le comportement des transactions dans SQL Azure. Tout comme nous l’avons mentionné, seules les transactions locales (au sein de la même base de données) sont prises en charge. De plus, le seul niveau d’isolement des transactions disponible pour une base de données hébergée sur SQL Azure est READ COMMITTED SNAPSHOT. À l’aide de ce niveau d’isolement, les lecteurs obtiennent la dernière version cohérente des données disponibles (instruction STARTED).

SQL Azure ne détecte pas les conflits de mise à jour. C’est ce que l’on appelle également un modèle d’accès concurrentiel optimiste car des pertes de mise à jour, des lectures non reproductibles et des fantômes peuvent se produire. Bien entendu, toute lecture erronée est impossible.

Administration de la base de données

En règle générale, en cas d’utilisation de SQL Azure, l’administrateur prend en charge la gestion logique de l’installation. La plateforme se charge quant à elle de la gestion physique. D’un point de vue pratique, cela signifie qu’aucun serveur physique ne doit être acheté, installé, corrigé, maintenu ou sécurisé. Il n’existe aucun moyen de positionner physiquement des fichiers, des journaux, des bases de données tempdb, etc. sur des emplacements physiques spécifiques. De ce fait, les commandes T-SQL USE <base de données>, FILEGROUP, BACKUP, RESTORE ou SNAPSHOT ne sont pas prises en charge.

Il n’existe non plus aucune prise en charge de SQL Agent sur SQL Azure. De même, il n’existe aucun moyen (ou besoin) de configurer la réplication, les envois de journaux, la mise en miroir de la base de données ou la mise en cluster. Si vous avez besoin d’assurer la maintenance d’une copie synchronisée et locale des schémas et des données SQL Azure, vous pouvez alors utiliser l’un des outils dont nous avons parlé plus haut pour la migration et la synchronisation des données. Ils fonctionnent dans les deux sens. Vous pouvez également utiliser la commande DATABASE COPY.

Outre le maintien de la synchronisation des données, quelles sont les autres tâches que les administrateurs ont besoin d’effectuer sur une installation SQL Azure ? 

Le plus souvent, il est nécessaire d’effectuer une administration logique. Il s’agit de tâches liées à la sécurité et la gestion des performances. De plus, vous devrez peut-être surveiller l’utilisation des capacités et les coûts associés. Pour vous aider dans ces tâches, SQL Azure propose un tableau de bord public Status History qui montre l’état de service actuel et l’historique récent (un exemple de cet historique est proposé dans la Figure 5) disponible à l’adresse microsoft.com/windowsazure/support/status/servicedashboard.aspx.

 

Figure 5 SQL Azure Status History

SQL Azure propose une sécurité élevée par défaut. SQL Azure force le chiffrement SSL avec toutes les connexions client autorisées (via les règles de pare-feu). Les connexions au niveau du serveur, ainsi que les utilisateurs et les rôles au niveau de la base de données sont également sécurisés. Il n’existe aucun rôle de niveau serveur dans SQL Azure. Le chiffrement de la chaîne de connexion fait partie des meilleures pratiques. De même, vous pouvez utiliser les certificats Windows Azure pour plus de sécurité. Pour en savoir plus, consultez l’article blogs.msdn.com/b/sqlazure/archive/2010/09/07/10058942.aspx.

Dans le domaine des performances, SQL Azure propose des fonctionnalités telles que la suppression automatique des transactions longue durée et des connexions inactives (plus de 30 minutes). Bien que vous ne puissiez pas utiliser SQL Profiler ni les indicateurs de trace pour optimiser les performances, vous pouvez par contre utiliser l’optimiseur de requête pour afficher les plans d’exécution des requêtes et les statistiques client. Vous pouvez également réaliser une gestion des statistiques et une optimisation de l’index au moyen des méthodes T-SQL standard.

Il existe également une liste de vues de gestion dynamique (qui couvre la base de données, l’exécution ou les données de transaction) pour l’administration de la base de données. Parmi ces vues, citons : sys.dm_exec_connections, _requests, _sessions, _tran_database_transactions, _active_transactions et _partition_stats. Pour une liste complète des vues de gestion dynamique prises en charge pour SQL Azure, lisez l’article msdn.microsoft.com/library/ee336238.aspx#dmv.

Notez également de nouvelles vues telles que sys.database_usage et sys.bandwidth_usage. Elles affichent le nombre, le type et la taille des bases de données, ainsi que l’utilisation de la bande passante de chaque base de données de sorte que les administrateurs puissent comprendre la facturation de SQL Azure. Un exemple vous est proposé Figure 6. Dans cette vue, la quantité est exprimée en Ko. Vous pouvez surveiller l’espace utilisé au moyen de la commande suivante :

 SELECT SUM(reserved_page_count) * 8192 FROM sys.dm_db_partition_stats

 

Figure 6 Utilisation de la bande passante dans SQL Query

Vous pouvez également accéder aux frais actuels de l’installation SQL Azure via le portail SQL Azure. Pour cela, cliquez sur le lien Billing dans l’angle supérieur droit de l’écran.

En savoir plus

Pour en savoir plus à propos de SQL Azure, je vous suggère de télécharger le kit de formation Windows Azure. Il propose une formation pratique sur SQL Azure, des livres blancs, des vidéos et bien plus encore. Ce kit de formation est disponible sur le site microsoft.com/downloads/details.aspx?FamilyID=413E88F8-5966-4A83-B309-53B7B77EDF78.

De même, vous pouvez lire le blog de l’équipe SQL Azure à l’adresse blogs.msdn.com/b/sqlazure/ et consultez le centre de développement MSDN SQL Azure à l’adresse msdn.microsoft.com/windowsazure/sqlazure.

Pour continuer à être informé des futures fonctionnalités de SQL Azure, visitez le site SQL Azure Labs à l’adresse suivante sqlazurelabs.com.                                                                                

Lynn Langit est évangéliste développeur pour Microsoft en Caroline du sud. Elle a publié deux livres sur la Business Intelligence avec SQL Server et a créé un ensemble de cours pour présenter la programmation aux enfants, cours que vous trouverez sur le site TeachingKidsProgramming.org. Lisez son blog à l’adresse blogs.msdn.com/b/SoCalDevGal.

Merci aux experts techniques suivants d’avoir relu cet article : George Huey et David Robinson