Avec l’arrivée de SQL Server 2008 R2, de nouveaux horizons s’ouvrent… Voici un rapide coup d’œil sur la fonction Data-Tier Application Components, qui devrait combler une partie du fossé entre les développeurs et les DBA.

Qu’est ce que le DAC ?
Il s’agit d’une entité qui contient tout ce dont une application peut avoir besoin : (tables, vues, fonctions, procédures, logins …). Une sorte de fichier MSI en quelques sortes.

A quoi cela peut-il servir ?
Cela permet de centraliser tous les objets en vue du déploiement d’une application. Jusqu’à la version SQL Server 2008 incluse, le déploiement d’une application (d’une base) passait par la création d’une nouvelle base sur le serveur de production, la création de scripts de tous les objets  sur le serveur de développement, la création de scripts pour les logins, etc … Un peu fastidieux, et surtout il ne fallait rien oublier. Même si des améliorations étaient arrivées avec SQL Server 2008 et la possibilité de créer des scripts (pouvant inclure les données), il manquait quelque chose.

Démo :

Sur serveur SQL en version 2008, je créé une base de test toute simple, contenant quelques tables avec des données, un login avec le user correspondant dans cette base.

Ensuite, explorons le menu contextuel des tâches en faisant un click droit :

Un nouvel item est apparu dans la version SQL Server 2008 R2 : “Extract Data-Tier Application”. Voici les copies d’écran de ce Wizard :

Notez l’extension des fichiers .dacpac. Ce fichiers ne sont pas “lisibles” avec SQL Server Management Studio, ce privilège devrait être donné aux utilisateurs de Visual Studio.

Au passage, nous pouvons voir que le Wizard propose une phase de validation. Tous les objets de base de donnée ne sont pas compatibles avec le DAC, comme nous le verrons plus tard.

Un peu de suspense .. Et c’est terminé, le fichier .dacpac est généré :

Sur mon instance SQL Server 2008 R2, click droit sur le nouvel élément présent dans le dossier Management :

Utilisons le wizard de déploiement :

Sélectionnons le fichier .dacpac créé précédemment :

Nous pouvons modifier le nom de la base, le nom de et l’emplacement des fichiers mdf, ndf et ldf.

Le compte rendu d’exécution nous montre clairement que les objets ont bien été créés, y compris les logins.

Nous pouvons aussi voir le package déployé :

Au final c’est un moyen facile d’accès pour déployer une base de données sur un serveur de production. par contre, si vous avez des tables contenant des données de référence, il faudra créer des packages SSIS spécifiques pour renseigner les valeurs de ces tables. Car le DAC ne créé que la structure des objets.

De plus, tous les objets ne sont pas pris en compte, voici le tableau des objets supportés :

J’aurais voulu mener des tests plus approfondis avec une base plus complexe mais je me suis heurté à une limitation que je trouve très gênante : si vous créez vos propres groupes de fichiers pour une base, ceux ci ne sont pas supportés.
Pour ma part, dans mes best practices, je préfère laisser tous les objets système dans le filegroup Primary et créer d’autres filegroups pour les données, les index, des blobs, etc … Et cette limitation devient réellement handicapante si on traite avec des tables partitionnées, auquel cas, le DAC ne peut pas s’appliquer. gageons que Microsoft saura corriger ce manque dans les prochaines CTP.

Pour faire machine arrière, un autre Wizard propose de détacher le base, de la supprimer ou bien de simplement supprimer le DAC :

En conclusion, c’est une nouveauté qui mérite que l’on s’y attarde, mais pour ma part, il y a encore trop de manques pour être réellement exploitable en production.

Mais on peut aussi se prendre à rêver d’un futur DAC permettant de “migrer” une application (une base de donnée) d’une instance SQL Server vers une autre en fonction du taux de charge des machines physiques. Hyper-V dans sa version 2 propose du live migration de machine virtuelle, pour ma part, j’attends avec impatience le livre migration de base de donnée …

Jusque là il était possible d’avoir une vision globale de l’activité d’un serveur au travers des DMWs et du rapport serveur dashboard,.

dans SQL Server 2008 R2 on va un peu plus loin en proposant l’Utility Explorer, une vue synthétique de l’activité de plusieurs instances :

Il est ainsi aisé de voir la charge CPU par machine (si celle ci héberge plusieurs instances SQL Server) et par instance. De même des indicateurs très clairs permettent d’avoir une vue synthétique sur l’espace disponible dans les bases est suffisant ainsi que l’espace libre sur les disques.

De là à imaginer que si une base plombe les performances de toute une instance, un click droit permette de la migrer sur une autre instance sans coupure de service, il n’y a qu’un pas !!! Hum hum, allez monsieur Microsoft, encore un effort … Le DAC s’apparente à une première étape …