Migrer un cube Analysis Services 2000 vers 2005

Le propos de ce billet n’est pas de fournir un tutoriel complet sur la migration de cubes entre AS 2000 et 2005 mais juste de présenter les méthodes pour le faire. Je ne présenterai que les points d’entrée, je ne rentrerai pas dans le détails des incompatibilités entre les versions.

Méthode 1 : In-place upgrade

C’est la méthode qui paraît la plus simple mais qui pour moi s’avère la plus risquée. En effet, j’ai toujours l’impression de tout miser sur un coup de dé.

J’appelle cette méthode la Next->Next->Next, car c’est tout simplement le setup d’installation de SQL Server 2005 qui va effectuer la migration du cube en 2005 et faire la bascule en redémarrant le service. Le processus de migration est équivalent à la méthode présentée ci-dessous sauf que tout est automatisé. La coupure de service est donc assez réduite (hormis le fait qu’il faille refaire une process du cube).

Avantages : pas de modification des clients, courte coupure de service
Inconvénients : risque d’incompatibilités

PS : utilisez l’Upgrade Advisor de SQL Server 2005 pour avoir un aperçu des problèmes que vous pourriez rencontrer.

Méthode 2 : la migration

Contrairement à ce qu’on pourrait penser, la migration n’est pas une méthode compliquée. On ne doit pas refaire complètement ses cubes. Un assistant livré avec Analysis Services 2005 permet de monter un cube à partir des méta-données d’un cube sous 2000.

Cet assistant s’appelle le MigrationWizard.exe et se trouve dans %programfiles%\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE.
On y accède aussi dans Management Studio avec un clic-droit sur l’instance Analysis Service 2005 comme présenté dans ce screenshot.

L’assistant est très intuitif et le résultat est très bien (mis à part les incompatibilités connues).
Il ne reste plus qu’à ouvrir notre nouveau cube dans Business Intelligence Development Studio (oui, je sais, Visual Studio) pour apporter si besoin des petits correctifs et le tour est joué.

Avantages : simplicité, on maîtrise le passage entre les versions
Inconvénients : changement de la chaîne de connexion des clients

 

Conclusion

Le choix de la méthode dépend de nombreux facteurs comme les utilisateurs et l’utilisation qu’ils font du cube, les données sources, la volumétrie, la conception initiale sous 2000, les incompatibilités remontées par l’Upgrade Advisor… Dans tous les cas, une migration se planifie et se prépare : audit, test, test, test, migration !

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s